On Thu, 15 Jan 2015, John Spray wrote: > On Thu, Jan 15, 2015 at 6:07 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > >> 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... :) > > The trouble with this is admin socket part is that any tool that > manages Ceph must use the admin socket interface as well as the normal > over-the-network command interface, and by extension must be able to > execute locally on a mon. We would no longer have a comprehensive > remote management interface for the mon: management tools would have > to run some code locally too. True.. if we make that option enabled by default. If we it's off by default them it's an opt-in layer of protection. Most clusters don't have ephemeral pools so I think lots of people would want this. > I think it's sufficient to require two API calls (set the flag or > config option, then do the delete) within the remote API, rather than > requiring that anyone driving the interface knows how to speak two > network protocols (usual mon remote command + SSH-to-asok). Yeah... 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
