[SSSD] sssd.conf ownership

Jakub Hrozek jhrozek at redhat.com
Mon Nov 24 09:57:55 UTC 2014


On Mon, Nov 24, 2014 at 10:12:20AM +0100, Lukas Slebodnik wrote:
> On (21/11/14 20:03), 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.
> SSSD will be running as root for sme time.

I'd like to do the switch in rawhide when we figure out the config ownership
and writing to the config by IFP. We've already put the code through
tests on our end, we're not going to find more issues without user's
help.

>Meanwhile we can file tickets
> to other projects.

How would you handle dependencies? Some versions of sssd require the
config to be owned by root, some by sssd.sssd..then add different
realmd/authconfig/ipa-client-install versions to the mix..

> 
> If the sssd will not start and there be error in syslog(journald) it will be
> very easy to change puppet modules.

So the admin pushes a change to the sssd.conf and then sssd on his
server doesn't start...that's exactly what I'm concerned about ...

> The more problematic situation can happen
> if users does not use any configuration management system. They would need to
> change ownership manually or we should do it after update
> (post section in spec file)

realm permit newadmin at example.com
systemctl restart sssd

...poof...

> 
> To sum up: I would prefer to get rid of root from as many places as possible.
> 
> LS
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list