On 01/15/2015 04:39 PM, Dan Van Der Ster wrote: > 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...) > Quick try, yes! Created a pool and user which only has access to that pool. I was able to remove that pool. > I can think of many ways that fat fingers can create crazy loads, deny client access, ... > Sure, but none of those actually make you loose your data. I know that you should create backups, but by accident removing a pool is something that is very dangerous and it will take a lot of time to restore from backups. > 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 ? > That would be great indeed. The client.admin key currently has all the capabilities and I would indeed like a RO account. But still, another safeguard against deleting pools would be something I'd like to see. Wido > 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 > -- 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
