Re: 'Immutable bit' on pools to prevent deletion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Wido,

+1 for safeguards.

Yeah that is scary: it's one api call to delete a pool, and perhaps even a client with w capability on a pool can delete it?? (I didn’t try...)

I can think of many ways that fat fingers can create crazy loads, deny client access, ...

 1. changing pool size
 2. setting pool quotas
 3. unplanned PG splitting
 4. creating an EC pool on a cluster with dumpling clients
 5. reweight-by-utilization
 6. changing crush rules/tunables

—yes-i-really-really-mean-it is nice when it’s there. But regardless it is probably not a good practice to work daily (or run librados cron jobs) in a shell that has access to the client.admin keyring. I’ve thought of using sudo to restrict our admin shell to subset of ceph admin commands. But even better would be a internal bit which locks out the API beneath “ceph osd pool …” and “ceph osd crush …”, even for client.admin.

Maybe this is already possible by creating a client.admin-readonly account for daily work and crons, and limit access to client.admin except when absolutely necessary ?

Cheers, Dan


> On 15 Jan 2015, at 15:46, Wido den Hollander <wido@xxxxxxxx> wrote:
> 
> Hi,
> 
> Although the userland tools like 'ceph' and 'rados' have a safeguard
> against fat fingers when it comes to removing a pool there is no such
> safeguard when using native librados.
> 
> The danger still exists that by accident you remove a pool which is then
> completely gone, no way to restore it.
> 
> This is still something I find quite dangerous, so I was thinking about
> a additional 'Immutable bit' which could be set on a pool before
> rados_pool_delete() allows this pool to be removed.
> 
> Is it a sane thing to look at 'features' which pools could have? Other
> features which might be set on a pool:
> 
> - Read Only (all write operations return -EPERM)
> - Delete Protected
> 
> It's just that looking at a 20TB RBD pool and thinking that just one API
> call could remove this pool make me a bit scared.
> 
> Am I the only one or is this something worth looking in to?
> 
> -- 
> Wido den Hollander
> 42on B.V.
> Ceph trainer and consultant
> 
> Phone: +31 (0)20 700 9902
> Skype: contact42on
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux