On (24/11/14 10:57), Jakub Hrozek wrote:
On Mon, Nov 24, 2014 at 10:12:20AM +0100, Lukas Slebodnik wrote:
> On (21/11/14 20:03), 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.
> 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
>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 ...
It's better to fail at the beginning. Let say we change owner of file after
startup. So we will expect it will have right owner and sssd_ifp can modify
file. But puppet will detect change in ownership and fix it.