| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Michal Židek <mzidek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the initial build of the Kerberos Cache Manager responder (KCM).
This is a deamon that is capable of holding and storing Kerberos
ccaches. When KCM is used, the kerberos libraries (invoked through e.g.
kinit) are referred to as a 'client' and the KCM deamon is referred to
as 'server'.
At the moment, only the Heimdal implementation of Kerberos implements the
KCM server:
https://www.h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html
This patch adds a KCM server to SSSD.
In MIT, only the 'client-side' support was added:
http://k5wiki.kerberos.org/wiki/Projects/KCM_client
This page also describes the protocol between the client and the server.
The client is capable of talking to the server over either UNIX sockets
(Linux, most Unixes) or Mach RPC (macOS). Our server only implements the
UNIX sockets way and should be socket-activated by systemd, although can
in theory be also ran explicitly.
The KCM server only builds if the configuration option "--with-kcm" is
enabled. It is packaged in a new subpackage sssd-kcm in order to allow
distributions to enable the KCM credential caches by installing this
subpackage only, without the rest of the SSSD. The sssd-kcm subpackage
also includes a krb5.conf.d snippet that allows the admin to just uncomment
the KCM defaults and instructs them to start the socket.
The server can be configured in sssd.conf in the "[kcm]" section.
By default, the server only listens on the same socket path the Heimdal
server uses, which is "/var/run/.heim_org.h5l.kcm-socket". This is,
however, configurable.
The file src/responder/kcm/kcm.h is more or less directly imported from
the MIT Kerberos tree, with an additional sentinel code and some
comments. Not all KCM operations are implemented, only those that also
the MIT client implements. That said, this KCM server should also be
usable with a Heimdal client, although no special testing was with this
hybrid.
The patch also adds several error codes that will be used in later
patches.
Related to:
https://pagure.io/SSSD/sssd/issue/2887
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sssd-nss.service attempts to chown its log file to ensure it has the
correct owner. Unfortunately, when this happens, it enters in a loop
trying to call into the name-service switch and hangs forever.
For now the approach taken is to just remove the ExecStartPre from the
NSS service.
Resolves:
https://pagure.io/SSSD/sssd/issue/3322
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although I didn't have any problem with this before I'd like to ensure
that the NSS socket is always up _before_ any other (SSSD) services'
sockets as they may trigger initgroups calls as some of them have
SocketUser and SocketGroup set to the "sssd" user.
Related:
https://pagure.io/SSSD/sssd/issue/3322
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NSS service is always run as root, so there's no need to change its
socket ownership to the sssd user.
More than that, by setting up the SocketUser and SocketGroup to "sssd"
a loop would be caused as the "sssd" would trigger an initgroups call
during the NSS socket setup.
The problem was found when starting up a machine with SSSD built with
"--with-sssd-user=sssd" and having "sss" before "files" in the
name-service switch.
Related:
https://pagure.io/SSSD/sssd/issue/3322
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
| |
This change is needed so that the InfoPipe responder can be socket
activated.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the responders will either be explicitly started by the monitor or
{dbus,socket}-activated, let's force them to refuse manual start, being
a little bit restricter on our side.
Resolves:
https://pagure.io/SSSD/sssd/issue/3300
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's ensure that in case a responder is explicitly configured in the
sssd.conf its socket won't even start.
The patchset introduces a new binary that will be distributed and will
be called before starting the responders' sockets, ensuring the sockets
will only start in case the responder is supposed to be socket-activated
and its been configured accordingly. Otherwise the responders' socket
startup will fail with a quite helpful debug message leading the admins
to choose between using systemd or not and what has to be done to achieve
their desire.
This suggestion came from Sumit Bose.
The reason for adding a new binary instead of a simple python script is
to avoid dragging unnecessary dependencies to sssd-common package.
Resolves:
https://pagure.io/SSSD/sssd/issue/3300
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As systemd adds "Before=sockets.target" to any socket unit by default,
during the startup of the system we can end up having a responder socket
up, being contacted while SSSD is shutdown.
By using "DefaultDependencies=no" we ensure that sockets.target won't
trigger the sockets' startup and that it only will be done when SSSD is
up. The downside of using "DefaultDependencies=no" is that we have to
deal with conflicts and add "Conflicts=shutdown.target" to each of the
sockets unit.
This patch has been suggested by Lukáš Nykrýn.
Related:
https://pagure.io/SSSD/sssd/issue/3298
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While debugging the whole breakage reported by Stric I've noticed that
the NSS socket has been starting up the NSS responder _before_ SSSD
being up. As libc does initgroups on pretty much any account and
initgroups checks all NSS modules in order to be precise, the nss_sss
triggers the NSS responder which would try talking to the data providers
which are not up uet (because SSSD is not up yet), causing the whole
process to hang until libc gives up (causing a timeout on services like
systemd-logind and on services depending on this one).
By adding this ordering explicitly we can avoid the reported situation.
Also, it has been recommend by Lukáš Nykrýn that "BindsTo", which is
used to tie up two services, and After must be used together in order to
avoid undefined/unexpected behavior (although it's still not mentioned
in the systemd documentation).
Related:
https://pagure.io/SSSD/sssd/issue/3298
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
| |
We changed type forking into type notify as part of commit
d4063e9a21a4e203bee7e0a0144fa8cabb14cc46.
But we forgot to update template drop-in file for logging into journald.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responders socket-activatable (or,
in the IFP case, dbus-activatable), let's make the IFP responder ready
for this by providing its systemd's units.
Related:
https://fedorahosted.org/sssd/ticket/2243
Resolves:
https://fedorahosted.org/sssd/ticket/3129
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responder socket-activatable, let's
make Sudo responder ready for this by providing its systemd's units.
In case the administrators want to use Sudo responder taking advantage
of socket-activation they will need to enable sssd-sudo.socket and
after a restart of the sssd service, the Sudo socket will be ready
waiting for any activity in order to start the Sudo responder. Also,
the Sudo responder must be removed from the services line on sssd.conf.
The Sudo responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responder socket-activatable, let's
make SSH responder ready for this by providing its systemd's units.
In case the administrators want to use SSH responder taking advantage
of socket-activation they will need to enable sssd-ssh.socket and after
a restart of the sssd service, the SSH socket will be ready waiting for
any activity in order to start the SSH responder. Also, the SSH
responder must be removed from the services line on sssd.conf.
The SSH responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responder socket-activatable, let's
make PAM responder ready for this by providing its systemd's units.
In case the administrators want to use PAM responder taking advantage
of socket-activation they will need to enable sssd-pam.socket and after
a restart of the sssd service, the PAM socket will be ready waiting for
any activity in order to start the PAM responder. Also, the PAM
responder must be removed from the services line on sssd.conf.
The PAM responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
PAM responder, differently from the others, is a special case as it has
two sockets and its private sockets must be owned by root and must have
a specifc permission (0600). It's not new, though, and it's following
what has been already done in the project..
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responder socket-activatable, let's
make PAC responder ready for this by providing its systemd's units.
In case the administrators want to use PAC responder taking advantage
of socket-activation they will need to enable sssd-pac.socket and after
a restart of the sssd service, the PAC socket will be ready waiting for
any activity in order to start the PAC responder. Also, the PAC
responder must be removed from the services line on sssd.conf.
The PAC responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responders socket-activatable, let's
make the NSS responder ready for this by providing its systemd's units.
In case the administrators want to use NSS responder taking advantage
of socket-activation they will need to enable sssd-nss.socket and after
a restart of the sssd service, the NSS socket will be ready waiting for
any activity in order to start the NSS responder. Also, the NSS
responder must be removed from the services line on sssd.conf.
The NSS responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
Is quite important to mention that NSS responder will always run as
root. The reason behind this is that systemd calls getpwnam() and
getgprnam() when "User="/"Group=" is set to something different than
"root". As it's done _before_ starting NSS responder, the clients would
end up hanging for a few minutes (due to "default_client_timeout"),
which is something that we really want to avoid.
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responders socket-activatable, let's
make the AutoFS responder ready for this by providing its systemd's
units.
In case the administrators want to use AutoFS responder taking advantage
of socket-activation they will need to enable sssd-autofs.socket and
after a restart of the sssd service, the AutoFS socket will be ready
waiting for any activity in order to start the AutoFS responder. Also,
the AutoFS responder must be removed from the services line on
sssd.conf.
The AutoFS responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
| |
Resolves:
https://fedorahosted.org/sssd/ticket/3080
Signed-off-by: Lukas Slebodnik <lslebodn@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
Resolves:
https://fedorahosted.org/sssd/ticket/3053
Documents the API and the purpose of the sssd-secrets responder.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds two new files: sssd-secrets.socket and sssd-secrets.service. These
can be used to socket-acticate the secrets responder even without
explicitly starting it in the sssd config file.
The specfile activates the socket after installation which means that
the admin would just be able to use the secrets socket and the
sssd_secrets responder would be started automatically by systemd.
The sssd-secrets responder is started as root, mostly because I didn't
think of an easy way to pass the uid/gid to the responders without
asking about the sssd user identity in the first place. But nonetheless,
the sssd-secrets responder wasn't tested as non-root and at least the
initialization should be performed as root for the time being.
Reviewed-by: Fabiano Fidêncio <fabiano@fidencio.org>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The syslog.target is not part of systemd anymore.
The non-socket-activated syslog daemons are not supported in systemd >= 35
and in the same version it was recomemded to not use this target in service
files.
http://www.freedesktop.org/wiki/Software/systemd/syslog/
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1088619
Before permitting user sessions sssd should be running. This also correctly
orders shutdown of sssd after the user sessions.
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
systemd supports overrides of the standard service file to be placed in
/etc/systemd/system/<service>.service.d/
With this patch, we will install a commented-out override file to /etc
that will instruct the user on how to enable logging to journald.
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
| |
https://fedorahosted.org/sssd/ticket/1959
|
| |
|
|
|
|
| |
This patch fixes the provided systemd unit file so it is the same
as the one Jóhann B. Guðmundsson provided in Red Hat Bugzilla #689853
except for hardcoded paths.
|
|
|
So far, the systemd unit file is only packaged but not used in any of
the packaged spec files.
Fixes: #483
|
