Bug 959418
| Summary: | thinlinc cannot create sessions on Fedora 19 (pam_loginuid problem) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pierre Ossman <ossman> |
| Component: | initscripts | Assignee: | Lukáš Nykrýn <lnykryn> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | astrand, eparis, gansalmon, iarlyy, itamar, jonathan, kernel-maint, lnykryn, madhu.chinakonda, mschmidt, plautrba, rvokal, vpavlin |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-02-17 15:08:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Are you getting an AVC denial? Nope. And I'm also running in permissive mode to minimise problem sources at this points. The only thing I'm getting in audit.log is this: type=USER_START msg=audit(1367583844.869:1211): pid=11764 uid=0 auid=0 ses=3 subj=unconfined_u:system_r:thinlinc_session_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="tltest" exe="/opt/thinlinc/libexec/tl-session" hostname=? addr=? terminal=? res=failed' which doesn't really tell me much. Which kernel are you seeing this with? Could you try and narrow down the latest kernel it worked with in f19? The builds are here: http://koji.fedoraproject.org/koji/packageinfo?packageID=8 If you're seeing this on 3.9, perhaps start with 3.9-rc1 and move forward until you hit it. If you hit it with 3.9-rc1, the make sure 3.8.11 in F18 still works. That will help us identify at least a range of commits to look at. Also, can you provide the strace output for the relevant section on a working kernel? Nevermind the requests. I recalled something about loginuid after I thought about it for a bit. This is done on purpose in F19 via the AUDIT_LOGINUID_IMMUTABLE config option. http://lists.fedoraproject.org/pipermail/kernel/2013-February/004125.html Eric, Michal, do you have suggestions for Pierre on getting this working with that option set? Pierre, I am not familiar with ThinLinc. Does it run as a daemon? How do you start it? Do you spawn it from a root's shell or does it have a proper systemd unit file or a SysV initscript? It uses SysV/LSB init files to start up. For this portion, there are three portions involved: vsmagent - the long term daemon that handles session startup and monitoring tl-session - the priviliged process that is spawned off for each session tl-xinit - the non-priviliged process that is spawned from tl-session Because of the problem here, we're stuck in tl-session as it fails to get through the stage of opening a PAM session. So looking at the commit referenced, it should really work. Because systemd should leave loginuid at -1 for vsmagent, which shouldn't touch it either. Could you verify that vsmagent runs with loginuid -1? cat /proc/$(pidof vsmagent)/loginuid -1 would actually show as "4294967295" (2^32 - 1). Ah. Found the issue. vsmagent was running with loginuid 0, not -1. And the reason for this was that it was started using the 'service' command, rather than systemctl. So it seems the bug is that 'service' is not correctly implemented on top of systemd, but instead executes LSB/SysV scripts directly. The redirection to systemctl relies on the initscript sourcing the "functions" script. There should be something like this near the beginning of the initscript: . /etc/rc.d/init.d/functions Without that the redirection does not work. Reassigning to initscripts for comments. (In reply to comment #10) > The redirection to systemctl relies on the initscript sourcing the > "functions" script. There should be something like this near the beginning > of the initscript: > > . /etc/rc.d/init.d/functions > > Without that the redirection does not work. That's not in LSB though. (neither is 'service' though, but there is nothing else suggested either so de facto standard will have to do) What is in LSB is /lib/lsb/init-functions, but those are not required to be included. Our init scripts are supposed to work on every LSB compliant system. So anything distribution specific I have to add makes my life so much more difficult. =/ /lib/lsb/init-functions does (indirectly) source /etc/init.d/functions, though it may not do it in a way that allows it to override properly. /sbin/service does redirect to systemctl - it's invoking the init script directly that requires the redirection bits. (In reply to comment #13) > /sbin/service does redirect to systemctl - it's invoking the init script > directly that requires the redirection bits. I beg to differ: [root@dhcp-254-223 log]# service vsmagent start Starting ThinLinc vsmagent [root@dhcp-254-223 log]# systemctl status vsmagent.service vsmagent.service - LSB: Start or stop the ThinLinc vsmagent Loaded: loaded (/etc/rc.d/init.d/vsmagent) Active: inactive (dead) since Fri 2013-05-03 22:00:54 CEST; 10s ago [root@dhcp-254-223 log]# cat /proc/`pgrep -f vsmagent`/loginuid 0 This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
I'm testing out ThinLinc on Fedora 19 and unfortunately it is unable to create any new user sessions. The problem is pam_loginuid which logs this to secure: May 3 14:24:04 dhcp-254-223 tl-session: pam_loginuid(thinlinc:session): set_loginuid failed I fired up strace, and it confirms that this is indeed broken: [pid 10993] open("/proc/self/loginuid", O_WRONLY|O_TRUNC|O_NOFOLLOW) = 3 [pid 10993] write(3, "1001", 4) = -1 EPERM (Operation not permitted) [pid 10993] close(3) = 0 I don't understand why it is getting EPERM though. It is running as root, and it seems to have the necessary permissions, as a later call to capget() shows: [pid 10993] capget({_LINUX_CAPABILITY_VERSION_3, 0}, NULL) = 0 [pid 10993] capget({_LINUX_CAPABILITY_VERSION_3, 0}, {CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_SETPCAP|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_ADMIN|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_MODULE|CAP_SYS_RAWIO|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_PACCT|CAP_SYS_ADMIN|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TIME|CAP_SYS_TTY_CONFIG|CAP_MKNOD|CAP_LEASE|CAP_AUDIT_WRITE|CAP_AUDIT_CONTROL|CAP_SETFCAP, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_SETPCAP|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_ADMIN|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_MODULE|CAP_SYS_RAWIO|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_PACCT|CAP_SYS_ADMIN|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TIME|CAP_SYS_TTY_CONFIG|CAP_MKNOD|CAP_LEASE|CAP_AUDIT_WRITE|CAP_AUDIT_CONTROL|CAP_SETFCAP, 0}) = 0 This works just fine on Fedora 18, so it is a regression in the new Fedora.