[SSSD] sssd.conf ownership

Michal Židek mzidek at redhat.com
Fri Nov 21 21:48:51 UTC 2014


On 11/21/2014 10:36 PM, Dmitri Pal wrote:
> On 11/21/2014 02:03 PM, 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?
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> You need to factor in our considerations about removing DB all together
> and merging data snippets of the file.
> Currently ding-libs can be instructed to make sure that the file and
> snippets should match specific user, group and permissions and would not
> use file that does not match.
> This is not used but SSSD yet but I hope will be used soon so this
> should be factored in while making the decision re sssd.conf ownership.
>
> Do we always run as non root now or it is a non default option?
>

For now, the default is root. Non root must be set-up as non-default
build time option and also set explicitly in the sssd.conf. The
default will probably change in some later release, when the non-root
is better tested.

Michal



More information about the sssd-devel mailing list