On Sun, Oct 28, 2012 at 4:26 AM, Dave Morgan <davemorgan353@btinternet.com> wrote:
What are the the technical reasons for group membership breaking functionality when using systemd?
With a typical desktop use case, systemd-logind's session management handles the ability to do things like use audio/video via ACLs: $ ls -l pcmC0D0c crw-rw----+ 1 root audio 116, 5 Oct 21 13:55 pcmC0D0c $ getfacl pcmC0D0c # file: pcmC0D0c # owner: root # group: audio user::rw- user:zekesulastin:rw- group::rw- mask::rw- other::--- ==But, if I login to a different user on another tty ...== $ getfacl pcmC0D0c # file: pcmC0D0c # owner: root # group: audio user::rw- user:cap:rw- group::rw- mask::rw- other::--- ==But when I switch back to x on vt1, the acl is set back to zekesulastin even though cap is still logged in== Adding a user to a group can cause this process to be subverted - logind can't manage who is in what group. (On audio again, in addition to the multiuser case this can also make it easier for a bad program to get around dmix/pulse if you use either.) There ARE still cases where you would want to put the user in a group (remote logins, jackd iirc, stuff not handled by ACLs if you have such a device), but for the typical desktop use case it is unnecessary. This is also why you have to start X on the same tty you logged in to if you're not using a DM - ck-launch-session was a workaround to that problem, but this workaround no longer exists.