On Fri, Nov 23, 2012 at 11:20:31AM +0000, Fons Adriaensen wrote:

On Fri, Nov 23, 2012 at 01:15:29AM +0300, MSal wrote:

...

Hello.

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?

This is not really systemd but logind meddling with device permissions to enforce its 'seat' and 'session' security scheme.

It's all a part of systemd.

Quoting Tom G.:

A brute-force way to avoid all of that is to "mask" it. I.e., symlink /etc/udev/rules.d/70-uaccess.rules to /dev/null.

Then use udev to assign group rights on audio devices to the 'audio' group, make sure that users who need audio are members of that group, and things will work as you want.

I was hoping for a cleaner solution. Maybe group session support where ACLs are applied on groups instead of users! Using ACLs for users only and voiding the historical support for groups is hardly progress. Or maybe I'm missing something. 70-uaccess.rules is not a backup file and AFAIK any modifications will be overwritten in the next update. I commented the line: SUBSYSTEM=="sound", TAG+="uaccess" and re-added the audio group as a workaround for now.

On Sat, Nov 24, 2012 at 08:26:00AM -0500, Zeke Sulastin wrote:

...

70-uaccess.rules is not a backup file and AFAIK any modifications will be overwritten in the next update.

Look up the NoUpgrade and NoExtract options in pacman.conf(5) :)

Still not a clean solution, IMHO. I want to deviate as little as possible from upstream/packaged configs. NoUpgrade means I'll be stuck with the current config file which might not be optimal 5 upgrades from now. Or even worse, it could become problematic.

On Sat, Nov 24, 2012 at 02:48:14PM +0100, Joakim Hernberg wrote:

On Fri, 23 Nov 2012 21:33:23 +0300 MSal <msal@tormail.org> wrote:

...

70-uaccess.rules is not a backup file and AFAIK any modifications will be overwritten in the next update.

I have no /etc/udev/rules.d/70-uaccess.rules on my system, i do have a /usr/lib/udev/rules.d/70-uaccess.rules though. I think creating the /etc/udev/rules.d/70-uaccess.rules to /dev/null symlink will override the standard rule and will not be overwritten by upgrading the udev package.

If /etc/udev/rules.d/70-uaccess.rules would be applied on top of /usr/lib/udev/rules.d/70-uaccess.rules , that would have been great. As one can try to revese the undesired rule and still incorporate all upgrades. But cancelling all the rules is a no go for me as I don't want to be running an almost unique setup just because udev/systemd/loginctl didn't think of group permissions. If systemd developers thought of supporting ACLs based on GIDs at least, this would have been a no issue.

Just to be clear, this isn't something the systemd developers came up with.

ConsoleKit was responsible applying the same ACLs for local sessions before.

To give credit where it's due thoough I could me misremembering, but don't CK and systemd share the same developers? CK was their first go at session permission management - as of spring 2011 or so they deprecated CK and absorbed its functionality into systemd / logind. gene/

On 11/25/2012 12:38 PM, Dave Reisner wrote:

Same developers? Not really[0]. Same company? Sure, Red Hat gets their paws on a lot of widely used Linux software (including being the largest corporate contributor to the kernel, at least in 2011).

[0] http://cgit.freedesktop.org/ConsoleKit/log/

d

Well I did suspect my memory was off - thanks for correcting ... shows clearly the initial git snap was 2006 or so ... and some of the systemd devs didn't get involved till a long while later. Thanks for clarifying the historical record ... gene

On Sat, Nov 24, 2012 at 07:00:10PM +0100, Tom Gundersen wrote:

On Nov 23, 2012 12:21 AM, "MSal" <msal@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.