[SSSD] sssd.conf ownership
Jakub Hrozek
jhrozek at redhat.com
Sat Nov 22 13:24:17 UTC 2014
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 ...
> 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..)
>
> So I guess I'm completely missing the need or advantage of chowning it.
More information about the sssd-devel
mailing list