On Sat, 2014-11-22 at 14:24 +0100, Jakub Hrozek wrote: > On Fri, Nov 21, 2014 at 04:26:58PM -0500, Stephen Gallagher wrote: > > > > > > > > On Fri, 2014-11-21 at 20:03 +0100, Jakub Hrozek wrote: > > > Hi, > > > > > > I was going through our design page that describes the rootless sssd and > > > I'd like to discuss the default ownership of sssd.conf a bit more. > > > > > > In the design document we proposed to change the default ownership to > > > sssd.sssd. This wouldn't widen sssd.conf access as only root and the sssd > > > user could read the config. One reason for the change was the dbus helper > > > to change the config, which would otherwise run privileged. > > > > > > But I wonder whether it's really the best approach. If we changed the > > > ownership to sssd.sssd, then we'd have to be careful about chowning the > > > file each time on startup because tools like authconfig or even customer's > > > puppet modules or whatnot will keep writing out the file as root.root. We > > > can't reasonably change all the external tools and chowning on each > > > startup seems a bit fragile (as opposed to chowning the databases which > > > is a one-time operation). > > > > > > Also, if we kept the the config file owned by root, then making the > > > confdb read-only for worker processes would mean the worker processes > > > have no means of altering the config file even if they were taken over. > > > > > > The downside of keeping the sssd.conf as root is that the augeas calls > > > would have to be moved to a setuid process -- and a new setuid process is > > > always a bit of a burden. > > > > > > To sum up: > > > * sssd.sssd > > > (+) don't need any privileged code to access sssd.conf > > > (-) need to chown the file on each startup > > > * root.root > > > (+) config file is only writable by privileged processes > > > (+) we're able to make the confdb read-only > > > (-) need privileged code to perform sssd.conf changes > > > > > > I do realize that the complexity of creating the setuid helpers is much > > > larger than the complexity of writing a function to chown a file, but > > > for some reason the chowning feels a bit fragile to me and my gut > > > feeling is that the config file would better be only accessible by > > > root... > > > > > > What do the other developers think? > > > > Why exactly would it need to be chown()ed? I'm unclear on that point. > > Presumably, SSSD is still being launched as root and then dropping > > privileges (otherwise it wouldn't be able to perform the chown). So to > > me it seems like it makes sense to just open the file read-only prior to > > dropping privileges, then pass the filehandle along. > > Passing a fd would be best, but infortunately the augeas API we use to > change the configuration only works with path names ... Hmm, that seems problematic and racy. There's no way for augeas to take a descriptor? That seems like a pretty big oversight. > > > The sssd can then > > generate the read-only confdb as the 'sssd' user. > > Normally yes, but if the user goes from root to non-root, we need to > chown the confdb anyway (we could also unlink as root and then generate > after we drop privileges..) > Right, unlink and generate as non-root was what I meant there. > > > > So I guess I'm completely missing the need or advantage of chowning it. > > _______________________________________________ > sssd-devel mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
