[SSSD] sssd.conf ownership

Jakub Hrozek jhrozek at redhat.com
Fri Nov 21 19:03:01 UTC 2014


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?



More information about the sssd-devel mailing list