pam_systemd works in tty but not within X or tmux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Mon, Nov 26, 2012 at 12:15:46AM +0300, MSal wrote:
> On Sat, Nov 24, 2012 at 07:00:10PM +0100, Tom Gundersen wrote:
> > On Nov 23, 2012 12:21 AM, "MSal" <msal@xxxxxxxxxxx> wrote:
> > > I asked about this in the forum. But it looks like this is a better
> > > place to discuss systemd-related issues.
> > >
> > > If I login to user1 or user2 then try to play audio which requires
> > > access to /dev/snd/* , proper access to the logged in user is set by
> > > the session and everything works correctly.
> > >
> > > But, if I login to user1 then su to user2, audio wouldn't work because
> > > access permissions are assigned to the session user only (user1).
> > >
> > > Any idea how to fix this issue?
> > 
> > Could you elaborate a bit on what you are trying to do? (there might be a
> > better way without using 'su'.
> > 
> > The behaviour you are getting is by design, so there is nothing really to
> > fix. However, you can of course make the system behave the way you want:
> > 
> > Either, assign your devices to the audio group and the same with your users.
> > 
> 
> .....
> 
> > Or add systemd_pam to the su pam file. This will create a new session for
> > you when you use su and should therefore adjust the ACLs accordingly.
> > 
> 
> pam_systemd is exactly what I was looking for. It works with
> systemd's/logind's upstream behaviour instead of working around it.
> 
> For reference, I added the following 2 lines to both /etc/pam.d/su{,-l}
> as I want a unified behaviour for all su invocations. Both files are
> backup which is an added plus:
> 
> session         required        pam_loginuid.so
> session         required        pam_systemd.so kill-session-processes=1
> 
> Warning: This will break su in already-open sessions.
> Note: "pam_loginuid.so" is an absolute requirement for this use-case not
> just a recommendation.
> 
> Check out `man 8 pam_systemd` and `man 8 pam_loginuid` for more info.

I spoke too soon. This doesn't work within X or tmux. su fails with
a PAM_SESSION_ERR message:

su: cannot not open session: Cannot make/remove an entry for the specified session

I think pts/<int> is for some reason considered an invalid argument for
tty. See logging output below.

I first enabled debugging:

-session         required        pam_systemd.so kill-session-processes=1
+session         required        pam_systemd.so kill-session-processes=1 debug=1

Then tried both cases:

1) logs from the tty case which works:

Nov 27 13:28:21 arch64 su[31178]: pam_systemd(su:session): Asking logind to create session: uid=0 pid=31178 service=su type=tty class=user seat=seat0 vtnr=2 tty=tty2 display= remote=no remote_user=user remote_host=
Nov 27 13:28:21 arch64 systemd-logind[955]: New session 47 of user root.
Nov 27 13:28:21 arch64 su[31178]: pam_systemd(su:session): Reply from logind: id=47 object_path=/org/freedesktop/login1/session/47 runtime_path=/run/user/0 session_fd=6 seat=seat0 vtnr=2

2) logs from within X or tmux where su fails at session creation:

Nov 27 13:29:21 arch64 su[31740]: pam_systemd(su:session): Asking logind to create session: uid=0 pid=31740 service=su type=tty class=user seat=seat0 vtnr=2 tty=pts/3 display= remote=no remote_user=user remote_host=
Nov 27 13:29:21 arch64 su[31740]: pam_systemd(su:session): Failed to create session: Invalid argument

The only difference is (tty=tty2) vs (tty=pts/3).


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux