On 11/22/2014 08:31 AM, Jakub Hrozek wrote:
On Fri, Nov 21, 2014 at 04:36:25PM -0500, 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 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
>> 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.
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.
You mean for reading the configuration?
It is already there.
You will open the file using (it just opens file and gets its FD and
stats stored, also saves some metadata in a handle)
int ini_config_file_open(const char *filename,
struct ini_cfgfile **file_ctx);
then drop privileges
then do the parsing.
You can tell it function above to collect stats at the moment you opened
the file and then perform access and ownership checks on it by using
ini_config_access_check or get stats structure yourself and poke at it.
If you need a function that already accepts FD that was opened it can be
added though I am not sure if it is needed as the function above seems
to do the trick but may be I am missing something.
On the saving side you effectively get a serialized buffer representing
configuration and then you would need to write it into file. I have not
got that point yet but it can be left to the application meaning SSSD to
deal with it for now.
> 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)
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 |
137 0, /* owned by root */
138 0, /* owned by root */
139 S_IRUSR, /* r**------ */
140 ALLPERMS & ~(S_IWUSR|S_IXUSR));
142 return EOK;
> Do we always run as non root now or it is a non default option?
As Michal said, it's non-default.
sssd-devel mailing list
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.