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. 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). John -- 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
