Bug 612712
Summary: | please enable pam_systemd by default | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lennart Poettering <lpoetter> |
Component: | authconfig | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 14 | CC: | 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-24 01:36:31 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Lennart Poettering
2010-07-08 20:36:25 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. Yes, it got accepted as feature for F14. ping? 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 ping? 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. http://admin.fedoraproject.org/updates/authconfig-6.1.8-1.fc14 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. |