[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