| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
We already log to syslog using pam_syslog() for logs generated directly
within our pam plugins. However, any logs generated by our generic logging
macros that are invoked within a pam plugin will log to the console. Let's
make sure our generic logging macros are set up to log to syslog as well.
|
| | |
|
| |
|
|
| |
Fixes #31375.
|
| |
|
|
| |
Continuation of b5b2510800fa50187f5c7342cb9471fdb97bc4b0.
|
| |
|
|
| |
To make it easier to debug issues like #31375.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
In pam_systemd.so and pam_systemd_home.so, we open a bus connection on
session close, which is called after fork. Closing the connection is
harmless, and should not warn about that.
This suppresses the following log message:
===
(sd-pam)[127]: PAM Attempted to close sd-bus after fork, this should not happen.
===
|
| |
|
|
|
|
|
|
|
| |
pam_prompt() will log very noisely at high error levels if it is called
without a conversation function that works. This is however a frequent
case, given that ssh doesn't provide one. To tone down the misleading
logging a bit, implement our own pam_prompt_graceful() that is just like
pam_prompt(), but reports errors back the caller who then logs (which we
generally do anyway).
|
| |
|
|
| |
Just to shorten a bit of code.
|
| |
|
|
|
|
|
| |
To cut off a string at some position we must set the "precision" not the
field width in format strings.
This led to some assert()s being hit where they really should not be.
|
| |
|
|
|
|
|
|
|
| |
There is some issue in our code that triggers this warning constantly,
but it's nothing users can solve, so downgrade to debug level until
we can figure out the original issue (which is a permission denied
error on ReleaseSession D-Bus method call).
Related to https://github.com/systemd/systemd/issues/28514
|
| |
|
|
| |
As reported by Fossies.org.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for systematically destroying connections in
pam_sm_session_open() even on failure, so that under no circumstances
unserved dbus connection are around while the invoking process waits for
the session to end. Previously we'd only do this on success, now do it
in all cases.
This matters since so far we suggested people hook pam_systemd into
their pam stacks prefixed with "-", so that login proceeds even if
pam_systemd fails. This however means that in an error case our
cached connection doesn't get disconnected even if the session then is
invoked. This fixes that.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Let's systematically avoid sharing cached busses between processes (i.e.
from parent and child after fork()), by including the PID in the field
name.
With that we're never tempted to use a bus object the parent created in
the child.
(Note this is about *use*, not about *destruction*. Destruction needs to
be checked by other means.)
|
| |
|
|
|
|
|
| |
When pam_end() is called after a fork, and it cleans up caches, it sets
PAM_DATA_SILENT in error_status. FDs will be shared with the parent, so
we do not want to attempt to close them from a child process, or we'll
hit assertions. Complain loudly and skip.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sd-bus connection is cached by the two pam modules globally, but this
can lead to issues due to hashmaps (used by sd-bus) using a global
static variable for the shared hash key, which is different per module
as both modules are loaded in the same process.
This happens because the sd-bus object is create in one module, but
used in the other, so global state does not match.
Use a different pam cache identifier for the sd-bus pointer, so that
each module uses a different sd-bus connection as a workaround.
Fixes https://github.com/systemd/systemd/issues/27216
Fixes https://github.com/systemd/systemd/issues/17266
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a primitive helper that wraps calls to pam_syslog() replacing
@PAMERR@ with pam_strerror() output in the format string. This allows for
a bunch of boilerplate to be removed.
@PAMERR@ is only supported at the end of the string. Similarly to %m,
realistically that's the only place where it is useful.
Note that unlike in logging functions in log.[ch], here the error value is
only used for the message and is not saved anywhere, so we don't need to
care about SYNTHETIC_ERRNO.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far our pam code was using strerror_safe(). But that's not a good approach,
because strerror_safe() is not thread-safe, and the pam code is "library code"
that should be thread-safe. In fact, the whole effort to use strerror() is
unnecessary, because pam_syslog() is documented to support %m. The
implementation in linux-pam simply uses vasprintf(). If we use %m too, we get
rid of the issue. The wrapper sets errno temporarily from the argument.
Apparently some PAM consumers run multiple PAM stacks in threads, so we should
avoid non-thread-safe code.
The new helper returns PAM_BUF_ERR for ENOMEM, and PAM_SERVICE_ERR in other
cases. This may change the returned code in some cases, but I think a) it
doesn't matter much, b) it's probably for the better. E.g. we might now return
PAM_SERVICE_ERR if the dbus message is borked, and PAM_SERVICE_ERR seems
appropriate.
|
| | |
|
| | |
|
| |
|
