Oh, I think it might be fine to require setting a config option before you delete stuff; I just don't want to prevent the option from being injectable. :) On Thu, Jan 15, 2015 at 10:07 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Thu, 15 Jan 2015, Gregory Farnum wrote: >> On Thu, Jan 15, 2015 at 9:44 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> > In addition (or instead of) making the API harder to fat-finger, we could >> > also add a mon config option like >> > >> > mon allow pool deletion = false >> > >> > that defaults off. Then, to delete any pool, you need to update ceph.conf >> > and restart mons or inject the config option change (ceph daemon >> > mon.`hostname` conig set ... on the leader) or the API will give you >> > EPERM. >> > >> > This offers some protection even for client.admin key users if we prevent >> > injectargs for that option (maybe feasible) and they don't have access to >> > the actual mon machine. >> >> What would that buy us? Preventing injectargs on it would require mon >> restarts, which is unfortunate ? and makes it sounds more like a >> security feature than a safety blanket. > > I meant 'ceph tell mon.* injectargs ...' as distinct from 'ceph daemon ... > config set', which requires access to the host. But yeah, if we went to > the effort to limit injectargs (maybe a blanket option that disables > injectargs on mons?), it could double as a security feature. > > But whether it may also useful for security doesn't change whether it is a > good safety blanket. I like it because it's simple, easy to implement, > and easy to disable for testing... :) > > sage > -- 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
