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" 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.