Am 25.04.2015 um 01:34 schrieb Sage Weil: > On Fri, 24 Apr 2015, Ken Dreyer wrote: >> Oh, my bad, sorry I missed that part of the pull request! Looks good to me. > > Still missing ceph.spec file changes, if you're up for it. :) I can change the spec files, but do we have finally some user/group IDs for RHEL/Fedora and SLE/openSUSE? > I'm working on the chown piece, but I'm not sure what to do about the > journal device (if it is a device). We can either > > - add ceph to the 'disk' group. This means it can scribble on any device > in the system, which seems less than ideal. I wouldn't do that. Especially from the security perspective. > - chown the journal device to ceph when the daemon is started. This > means the user can only scribble on other ceph devices, which seems about > right. But I'm not sure what the implications of chowning random devices > like /dev/sdc2 to ceph are. Not sure if this is what we want or that this is the "usual" way to handle these issues. > - do something tricky where we open the block device on startup before > doing the setuid, and reuse that file handle later. This likely screws up > all kinds layering because we want the privs to drop very eary (before we > start opening log files, for example) and only the journal code knows what > mode to open the file as. Any solution here will be kind of kludgey, I > think. The log files are not the issue here I guess since you can set the correct permissions outside of the daemons. If an OSD need to open a device it would be appropriate to open the device as root before dropping the privileges. The code shouldn't be that complicated we did such things e.g. in hald before. Another issue: there is the --enable-root-make-check configure option. I didn't take a look at the code yet, but does anybody know if these tests refer to something that needs root privileges within the daemons or is it due to testing something (like e.g. mount rbd's)? Danny -- 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
