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
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel