Bug 612712 - please enable pam_systemd by default
Summary: please enable pam_systemd by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: authconfig
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-08 20:36 UTC by Lennart Poettering
Modified: 2010-08-24 01:36 UTC (History)
1 user (show)

Fixed In Version: authconfig-6.1.8-1.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-24 01:36:31 UTC


Attachments (Terms of Use)

Description Lennart Poettering 2010-07-08 20:36:25 UTC
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 08:56:03 UTC
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 18:33:01 UTC
Yes, it got accepted as feature for F14.

Comment 3 Lennart Poettering 2010-07-21 18:25:45 UTC
ping?

Comment 4 Bug Zapper 2010-07-30 12:28:56 UTC
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 10:36:47 UTC
ping?

Comment 6 Tomas Mraz 2010-08-04 13:12:53 UTC
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 12:16:28 UTC
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 13:20:56 UTC
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 15:57:19 UTC
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-11 02:56:10 UTC
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-24 01:36:22 UTC
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.