| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing the secrets key, the code tried to protect against malformed keys
or keys that are too short, but it did an error - the UUID stringified
form is 36 bytes long, so the UUID_STR_SIZE is 37 because UUID_STR_SIZE
accounts for the null terminator.
But the code, that was trying to assert that there are two characters after
the UUID string (separator and at least a single character for the name)
didn't take the NULL terminator (which strlen() doesn't return) into
account and ended up rejecting all ccaches whose name is only a single
character.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
Existing with memory database would be fatal as we keep the ccaches in
memory then, but if the ccaches are stored in sssd-secrets, we can just
exit on idle.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
In order to avoid race conditions, we queue requests towards the KCM
responder coming from the same client UID.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
Adds a new option 'ccache_storage' that allows to select either the
memory back end or the secrets back end. The secrets back end is the
default one and this option is even undocumented.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
| |
Adds a new KCM responder ccache back end that forwards all requests to
sssd-secrets.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements the actual KCM server operations. On a high level, each
operation unmarhalls the needed data from the input buffer, calls into
the ccache db and marshalls a response.
Only the operations that are also implemented by the MIT client are
implemented by our KCM server.
Resolves:
https://pagure.io/SSSD/sssd/issue/2887
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
| |
Implements a simple back end for the ccache module that lets the KCM
server store credentials directly in memory.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In order for the KCM server to work with ccaches stored in different
locations, implement a middle-man between the KCM server and the ccache
storage.
This module has asynchronous API because we can't assume anything about
where the ccaches are stored.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements parsing the KCM client request into per-client buffers and
sending a response for both the failure case and for success.
The protocol is documented at:
http://k5wiki.kerberos.org/wiki/Projects/KCM_client
Several places don't use the sss_iobuf structure, because they don't
parse variable-length data from the buffer and it's much more efficient
to just allocate the needed request and reply structure on the stack.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@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>
|
