Bug 959418 - thinlinc cannot create sessions on Fedora 19 (pam_loginuid problem)
Summary: thinlinc cannot create sessions on Fedora 19 (pam_loginuid problem)
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukáš Nykrýn
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-03 12:33 UTC by Pierre Ossman
Modified: 2015-02-17 15:08 UTC (History)
13 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-02-17 15:08:40 UTC


Attachments (Terms of Use)

Description Pierre Ossman 2013-05-03 12:33:59 UTC
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.

Comment 1 Josh Boyer 2013-05-03 12:38:08 UTC
Are you getting an AVC denial?

Comment 2 Pierre Ossman 2013-05-03 12:40:40 UTC
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.

Comment 3 Josh Boyer 2013-05-03 12:50:26 UTC
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.

Comment 4 Josh Boyer 2013-05-03 12:51:55 UTC
Also, can you provide the strace output for the relevant section on a working kernel?

Comment 5 Josh Boyer 2013-05-03 13:23:16 UTC
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?

Comment 6 Michal Schmidt 2013-05-03 13:36:00 UTC
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?

Comment 7 Pierre Ossman 2013-05-03 14:57:15 UTC
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.

Comment 8 Michal Schmidt 2013-05-03 15:03:24 UTC
Could you verify that vsmagent runs with loginuid -1?
cat /proc/$(pidof vsmagent)/loginuid

-1 would actually show as "4294967295" (2^32 - 1).

Comment 9 Pierre Ossman 2013-05-03 15:11:44 UTC
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.

Comment 10 Michal Schmidt 2013-05-03 15:19:16 UTC
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.

Comment 11 Michal Schmidt 2013-05-03 15:21:46 UTC
Reassigning to initscripts for comments.

Comment 12 Pierre Ossman 2013-05-03 15:26:55 UTC
(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. =/

Comment 13 Bill Nottingham 2013-05-03 18:35:15 UTC
/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.

Comment 14 Pierre Ossman 2013-05-03 20:02:58 UTC
(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

Comment 15 Fedora Admin XMLRPC Client 2013-09-04 14:50:38 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 16 Fedora End Of Life 2015-01-09 18:01:56 UTC
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.

Comment 17 Fedora End Of Life 2015-02-17 15:08:40 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.