[arch-general] [fixed in 196] Re: pam_systemd works in tty but not within X or tmux

[MSal]

On Tue, Nov 27, 2012 at 04:55:02PM +0300, MSal wrote:
> 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 at tormail.org> 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).

fwiw, this is fixed in 196.

Access seems to be revoked mid-session sometimes for some reason. But
`su $USER` fixes that(by creating a new session).

I hope systemd/logind will get more mature with time so users wouldn't
have to live with those quirks.