On Mon, Jul 28, 2014 at 06:29:39AM -0400, Simo Sorce wrote:
On Wed, 2014-07-23 at 20:52 +0200, Jakub Hrozek wrote:
> On Wed, Jul 23, 2014 at 06:39:40PM +0200, Sumit Bose wrote:
> Yeah, unfortunately maintenance is taking most of the time :-/
>
> That brings one question -- should the user to run as be configurable
> during runtime, too?
I'd prefer this, I see no reason to hardcode it at build time.
> Most deamons allow this and perhaps being able to
> specify something like:
>
> [sssd]
> user = sssd
> group = sssd
>
> or conversely:
>
> [sssd]
> user = root
> group = root
>
> Might be a good way to have a workaround if we missed some corner case
> that doesn't work with unprivileged process. Then, after we are
> confident that all use cases work fine we could "just" flip the
> defaults.
Sounds a good cautious approach, and allows users to flip back to root,
should some corner case fail still.
OK, thanks, added to the design page as well as your IRC notes about
merging ldap_child and krb5_child.
> >
> > >
> > > >
> > > > We should try to be more ambitious here and say that SSSD can be
started
> > > > as unprivileged user i.e. none of the long running daemons run as
root
> > > > at any time. systemd offer option like User= and Group= start start
> > > > daemons as any use, additionally it offers Capabilities= so the we
can
> > > > keep some capabilities, e.g. to send audit messages.
> > >
> > > Yes, if the monitor can run as non-root, too. Currently I think the only
> > > reason to run as root is to be able to spawn worker processes that start
> > > as root.
We may need some capability to monitor interfaces/files ?
Currently we monitor the resolv.conf and the netlink socket, none of
which requires root privileges. If we need to keep the root privs for
the proxy backend, though, it's just an academic discussion..