Bug 612712 - please enable pam_systemd by default
please enable pam_systemd by default
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-07-08 16:36 EDT by Lennart Poettering
Modified: 2010-08-23 21:36 EDT (History)
1 user (show)

See Also:
Fixed In Version: authconfig-6.1.8-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-23 21:36:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lennart Poettering 2010-07-08 16:36:25 EDT
As part of the integration of systemd into Fedora, I'd like to ask that pam_systemd is activated by default in /etc/pam.d/system-auth.

pam_systemd automatically creates a cgroup for each user and each session, and depending on configuration can ensure that when the user logs out all members of these groups are killed again. (Among other things) For further details about this PAM module see the man page:


The suggested line goes something like this:

-session required pam_systemd.so

The "-" makes sure that this line only matters if pam_systemd is actually installed, which is still optional at this point in time. This way a dependency between pam and systemd is not necessary. Also note that pam_systemd.so even when installed is a NOP when the system was actually not booted with systemd. That should ensure that things stay robust.

I am a bit puzzled how authconfig interferes with /etc/pam.d/system-auth. Does it override the default file from the pam package? Do I need to file another bug for that?
Comment 1 Tomas Mraz 2010-07-09 04:56:03 EDT
Is the systemd by-default now official project for Fedora 14?

For now I think that having it by default set up by authconfig should be good enough as authconfig is always run by anaconda when the system is installed.
Comment 2 Lennart Poettering 2010-07-09 14:33:01 EDT
Yes, it got accepted as feature for F14.
Comment 3 Lennart Poettering 2010-07-21 14:25:45 EDT
Comment 4 Bug Zapper 2010-07-30 08:28:56 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
Comment 5 Lennart Poettering 2010-08-04 06:36:47 EDT
Comment 6 Tomas Mraz 2010-08-04 09:12:53 EDT
I was away and also doing other high priority things, so sorry for getting to only now.

Is it now at all possible to not have pam_systemd on the system? If not I could omit the '-'.
Comment 7 Tomas Mraz 2010-08-05 08:16:28 EDT
Hmm actually it seems that systemd is still allowed to not be installed. Thus the module would have to be with '-' and also it cannot be 'required' but 'optional'. I am also not quite sure it should be in the central config files (system-auth, etc.). Shouldn't it be just in /etc/pam.d/[gk]dm*, /etc/pam.d/login and possibly /etc/pam.d/sshd?

Should the module also affect for example the cron jobs? What happens if 'su - user' is run as root?

Also what happens when I do 'su -' from the user's login prompt and start up for example some long lived daemon such as httpd from the shell (suppose that I have set kill_session=1)?
Comment 8 Lennart Poettering 2010-08-10 09:20:56 EDT
Either "optional" or "required" is fine for me.

It should be safe to put pam_systemd in everything that sets up a new session. The systemd session is bound to the audit session, so wherever audit creates a new audit session id we will compliment this with a systemd cgroup. If we are called recursively for the same audit session id we won't do anything. 

Thus, like the audit session we will not create a new session cgroup when the user uses su or sudo. We do it like this on purpose.

If you enable kill-session=1, then everything that is part of the session will be killed on logout. If you started apache from it apache will be killed too. I'd consider this a feature, not a bug. If you want to start stuff outside a session, then explicitly do that, for example by using systemd's daemon startup/maintenance code. 

Something similar applies to the "screen" tool: if you use "kill-session=1" then it would be killed on logout. Which I think is the right thing. If the admin wants to allow screens to be around he should either not use "kill-session=1" (given that he wants stuff started from the session to stay around aftzer the session is closed this is literally what the option is for), or he should make screen create its own auditing and systemd session. Currently screen does not call into PAM for this, but this would definitely be thinkable.

Note that it is easy to move processes between cgroups. i.e. if you the admin wants to move his shell into a different group this is sufficient:

$ mkdir /cgroup/systemd/foo
$ echo $$ > /cgroup/systemd/foo/tasks

And that's it.

Note that kill-user= and kill-session= default to off to not break screen. The admin should enable this option iff he wants to make it impossible to keep screens around for users that logged out.
Comment 9 Fedora Update System 2010-08-10 11:57:19 EDT
authconfig-6.1.8-1.fc14 has been submitted as an update for Fedora 14.
Comment 10 Fedora Update System 2010-08-10 22:56:10 EDT
authconfig-6.1.8-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update authconfig'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/authconfig-6.1.8-1.fc14
Comment 11 Fedora Update System 2010-08-23 21:36:22 EDT
authconfig-6.1.8-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.