On 08/31/2016 10:16 PM, Jakub Hrozek wrote:
On Wed, Aug 31, 2016 at 07:40:32PM +0200, Fabiano Fidêncio wrote:
> Taking a look on https://fedorahosted.org/sssd/ticket/2395
> there are a few ways to achieve what's proposed by Simo and I'd like
> to discuss one of those before start implementing it.
> As far as I understand the bug, SSSD cannot be run as a non-root user
> because of IFP responder, which needs to be run as root in order to
> write to sssd.conf file.
SSSD can under most circumstances run as non-root, but not all of it and
not in all setups. The InfoPipe responder can never run as root because
of the config-changing piece. The AD provider needs to touch krb5.conf
when it generates domain-realm mappings.
But the InfoPipe is the last component that can never run as root and
(re)moving the config modification piece would make it at least possible
to run as non-root.
> Simo's suggestion was to create a new
> service, which should be socket-activated, to handle this writing to
The IFP service has a D-Bus API, so it should be bus-activated.
> sssd.conf part and Jakub's suggested to completely get rid of this
> part. However, Dmitri pointed out that we must have some service
> playing with sssd.conf as it's the way that cockpit and ansible can
> remotely manage the SSSD configuration.
First, sorry if I contradict what I told you on IRC in this mail, but only
now did I look at the config API and realized it doesn't really change the
config per se, but mostly allows enabling and disabling services and domains.
Which makes me wonder if it would still be useful if we implemented
the bus/socket activation instead, because if the responders were socket
activated and thus represented as their own service, consumers like cockpit
or ansible could just use the existing systemd API to enable the sssd
services just like any other service.
Sure, the API still offers a way to enumerate services, but is that
really useful enough to maintain a separate API? I think this is the
most important question to figure out.
So I would suggest to actually first think about how we'd want to make sssd
services manageable better and start working on the well-defined tasks around
the bus activation and socket activation and /then/ decide if we want to keep
the config changing API around. And about cockpit and Ansible -- this API
was around for several years, if anyone wanted to use it, they already would..
We should just rip the code out of IFP completely, since it has very
small feature set and relies on Augeas.
Either per request or if we decide to start cooperation with Cockpit or
Ansible, we will design config changing over D-Bus from scratch to fit
their needs and to do it right, based on ding-libs write API. This will
be in new responder service, say ConfPipe.
That beeing said, we don't need to bother with it right now.
> Okay, in order to actually start solving the issue I'd like
> the follow steps:
> 1) Create a new service, still explicitly enabled in sssd.conf, that
> would take care of the managing the SSSD configuration.
> 2) Get rid of the code dealing with the SSSD configuration from the
> IFP responder.
> 3) Get rid of the OpenLMI specific code from the IFP responder
> Till this point the problem wasn't solved at all, but those seem to be
> the logical steps in order to make our own lives easier for working in
> the next two steps.
> 4) Make the new service (created in 1) socket-activated/bus-activated.
> 5) Make the IFP responder also bus-activated/socket-activated.
> So, does it sound like a reasonable way to approach the problem?
> If yes, I'd like to ask a few questions, mainly about items 4 and 5,
> as it eems that in order to achieve what we want,
have to be solved together,
> which seems to be a not so small task.
The code to do socket-activation (for responders that communicate over a
UNIX socket) is there already, that's how the sssd-secrets responder is
started. I'm not totally sure about bus-activation, but I don't think
much/any code changes in sssd would be needed, it would be more of a
plumbing work to create the services. I think the bus-activation is a
task that can be worked on already.
I didn't read the socket-activation code. If it is complete -- good. To
enable it on all service, we need to switch logic in the monitor (and
eventually get rid of it completely).
Current logic is:
- create mt_svc for service
- start managing service (relay signals, restart service)
- run service and wait for registration
With socket/bus activation, the logic should be:
- wait for service registration
- start managing service (relay signals)
What we also need is a way to manage the bus-activated services
Right now, if a bus-activated service is started, it is running forever,
we need some to implement some idle timeout. This is a task that can be
tackled already for the secrets responder.
Right now, it is not possible to bus-activate any responder. It is not
Good thing is, that bus-activation itself is for free, since it is
already implemented in systemd/dbus. We just need to enable it by
changing logic of monitor (see above).
Related to that, if the service was socket-activated, but then the
changes sssd.conf and restarts sssd, the service never re-reads its
configuration. Maybe this could be just solved with a Requires/Wants
between the individual services and the sssd services, not sure, but
it's something to work on.
> So, do we have to care about systems that don't have systemd support?
> IOW, do we have to keep the current code and also add
> socket-activation? If yes, would it be explicitly enabled/disabled on
> configure time? Maybe a lame question, but what are the advantages of
> the socket-activation over the bus-activation approach (I still didn't
> look at any of those :-\)?
socket-activation is meant for services that communicate over a UNIX
socket, like nss, pam or sudo. The goal is to let systemd start these
services only when they are needed, iow when a client writes to the
bus-activation is meant for services that export a D-Bus API, currently
that's the IFP responder. The goal is to let systemd/dbus start this
service once someone accesses some method it exports.
What we have now is a way to start a service when sssd starts and keep
it running until the sssd service is stopped, which is a bit wasteful
especially for services that are seldom needed (ssh, autofs, sudo). This
is done by explicitly listing the service in the 'services' line -- and
this method should stay there for non-systemd systemd and to make it
possible to let services always running in case the admin wanted to
eliminate the startup delay of on-deman activation for example.
sssd-devel mailing list