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
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..
Okay, in order to actually start solving the issue I'd like to propose
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
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.
What we also need is a way to manage the bus-activated services better.
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.
Related to that, if the service was socket-activated, but then the admin
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.