Bug 612712

Summary: please enable pam_systemd by default
Product: [Fedora] Fedora Reporter: Lennart Poettering <lpoetter>
Component: authconfigAssignee: Tomas Mraz <tmraz>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: authconfig-6.1.8-1.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-23 21:36:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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:

http://0pointer.de/public/systemd-man/pam_systemd.html

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
ping?
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Lennart Poettering 2010-08-04 06:36:47 EDT
ping?
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.
http://admin.fedoraproject.org/updates/authconfig-6.1.8-1.fc14
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.