| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
We want that elogind --user gets its own keyring as usual, even if the
barebones PAM snippet we ship upstream is used. If we don't do this we get the
basic keyring elogind --system sets up for us.
|
| |
|
|
|
|
| |
Otherwise elogind-user@ fails because elogind validates the account
Fixes: #4342
|
| |
|
|
|
|
|
|
| |
It is impossible to ship a fully generic PAM configuration upstream.
Therefore, ship a minimal configuration with the elogind --user requirements,
and add a note to DISTRO_PORTING documenting this.
Fixes #4284
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This way the user service will have a loginuid, and it will be inherited by
child services. This shouldn't change anything as far as elogind itself is
concerned, but is nice for various services spawned from by elogind --user
that expect a loginuid.
pam_loginuid(8) says that it should be enabled for "..., crond and atd".
user@.service should behave similarly to those two as far as audit is
concerned.
https://bugzilla.redhat.com/show_bug.cgi?id=1328947#c28
|
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1262933
|
