Red Hat Bugzilla – Bug 612712
please enable pam_systemd by default
Last modified: 2010-08-23 21:36:31 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?
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.
Yes, it got accepted as feature for F14.
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:
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 '-'.
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)?
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.
authconfig-6.1.8-1.fc14 has been submitted as an update for Fedora 14.
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
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.