On 11/21/2014 10:36 PM, Dmitri Pal wrote:
> On 11/21/2014 02:03 PM, Jakub Hrozek wrote:
>> I was going through our design page that describes the rootless sssd
>> 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
>> user could read the config. One reason for the change was the dbus
>> 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
>> 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
>> What do the other developers think?
>> sssd-devel mailing list
> 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.
If this is the case then it is a corner case and I would just fail if
the file has wrong permissions or as Stephen suggested access it before
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.