[SSSD] sssd.conf ownership

Jakub Hrozek jhrozek at redhat.com
Sat Nov 22 13:31:40 UTC 2014


On Fri, Nov 21, 2014 at 04:36:25PM -0500, 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.

Even if we remove db and pass along some in-memory structure, the
question on config file ownership still stands.

> 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.

Do your plans include API that accepts a FD as opposed to a file path? That
would enable us to use Stephen's suggestion.

> 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.

It is used :-)

130 int sss_ini_config_access_check(struct sss_ini_initdata *init_data)                                                                                                                 
131 {                                                                                                                                                                                   
132 #ifdef HAVE_LIBINI_CONFIG_V1                                                                                                                                                        
133     return ini_config_access_check(init_data->file,                                                                                                                                 
134                                    INI_ACCESS_CHECK_MODE |                                                                                                                          
135                                    INI_ACCESS_CHECK_UID |                                                                                                                           
136                                    INI_ACCESS_CHECK_GID,                                                                                                                            
137                                    0, /* owned by root */                                                                                                                           
138                                    0, /* owned by root */                                                                                                                           
139                                    S_IRUSR, /* r**------ */                                                                                                                         
140                                    ALLPERMS & ~(S_IWUSR|S_IXUSR));                                                                                                                  
141 #else                                                                                                                                                                               
142     return EOK;                                                                                                                                                                     
143 #endif                                                                                                                                                                              
144 }   

> 
> Do we always run as non root now or it is a non default option?

As Michal said, it's non-default.



More information about the sssd-devel mailing list