[arch-general] systemd and local group membership
Hi, The systemd wiki article says: "Note: Adding your user to groups (optical, audio, scanner, ...) is not necessary with systemd. It might even break the wanted functionality if you do so." What are the the technical reasons for group membership breaking functionality when using systemd? -- Dave.
"Note: Adding your user to groups (optical, audio, scanner, ...) is not necessary with systemd. It might even break the wanted functionality if you do so."
While I ignore the technical reasons, my scanner does not work if I am not in the scanner group.
On Sun, Oct 28, 2012 at 12:29 PM, Giorgio Lando <giorgio.lando@gmail.com> wrote:
"Note: Adding your user to groups (optical, audio, scanner, ...) is not necessary with systemd. It might even break the wanted functionality if you do so."
While I ignore the technical reasons, my scanner does not work if I am not in the scanner group.
That is a bug (or potentially a misconfiguration, though I cannot imagine exactly how). The way it should work is: The udev rules shipped with sane (53-sane.rules) will make the scanner group the owner of your scanner device and add an environment variable for the device: "ENV{libsane_matche}=yes" to the udev db. Based on this variable, the rules shipped with logind (70-uaccess.rules) will add the "uaccess" tag to the udev db for the scanner device. That tag is what tells logind which devices to assign ACL's to (as described by Zeke earlier in this thread). If you are having a problem with this, please open a bug report, making sure that you are running systemd, that your user session is registered and considered active by logind (use loginctl to check) and that sane is installed. Attach the output of "udevadm info /dev/<your scanner>" to the bug report. Cheers, Tom
Excerpt from Giorgio Lando's message of 2012-10-28T12:29+0100:
"Note: Adding your user to groups (optical, audio, scanner, ...) is not necessary with systemd. It might even break the wanted functionality if you do so."
While I ignore the technical reasons, my scanner does not work if I am not in the scanner group.
Indeed, if I'm not in the optical group, K3b doesn't work. (I'm running Xfce, not KDE; I don't know if it is related).
On Mon, Oct 29, 2012 at 12:49 PM, F.Gr. <frgroccia@gmail.com> wrote:
Excerpt from Giorgio Lando's message of 2012-10-28T12:29+0100:
"Note: Adding your user to groups (optical, audio, scanner, ...) is not necessary with systemd. It might even break the wanted functionality if you do so."
While I ignore the technical reasons, my scanner does not work if I am not in the scanner group.
Indeed, if I'm not in the optical group, K3b doesn't work. (I'm running Xfce, not KDE; I don't know if it is related).
As explained above, you need to check that your user session is considered active by logind for it to apply the ACL's to your devices. When it comes to CD burning software there is the additional caveat that by default the udev rules only apply ACL's (and group ownership) to the "modern" cdrom device nodes, and not the legacy ones. Depending on your cdrom software this may or may not be a problem. As I have filed my cdrom drive together with my telefax, I haven't tested this stuff myself in quite some time. -t
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.
Nice explanation Zeke. Just one comment: On Sun, Oct 28, 2012 at 3:17 PM, Zeke Sulastin <zekesulastin@gmail.com> wrote:
Adding a user to a group can cause this process to be subverted - logind can't manage who is in what group.
This means that both the user granted permissons by ACL, and the user granted permission by being in the right group will have access to the device. In other words, if your user had access without logind/CK s/he will still have access with. The problem might be that programs now rely on logind/CK to _take away_ permissions from inactive users to make sure that at most one user has access to the device at any given time. -t
On Sun, Oct 28, 2012 at 06:08:46PM +0100, Tom Gundersen wrote:
This means that both the user granted permissons by ACL, and the user granted permission by being in the right group will have access to the device. In other words, if your user had access without logind/CK s/he will still have access with.
The problem might be that programs now rely on logind/CK to _take away_ permissions from inactive users to make sure that at most one user has access to the device at any given time.
You (Tom) pointed out a way to disable logind modifying device ACLs recently. It could be a good thing to have that in the online docs for those users (like me) for whom this sort of thing is unwanted. Logind's behaviour seems to be based on two assumptions: 1. A non-local user (not near the system's HW) can't do anything useful with e.g. audio interfaces. 2. A local user (having access to the system's HW) can do whatever evil he wants so there's no point in taking away any permissions. Both can easily be wrong. For example at one of the audio studios I work, the audio processing machines are headless and mounted in a rack in a separate technical room. They are used via SSH logins or by using remote control protocols. But all the audio inputs and outputs of their soundcards are wired to the mixer or the patchbay in the studio, so they are 'local' there - this violates (1). For (2), a local user can do whatever evil only if he has unlimited time and is not supervised. I routinely let clients login to the local machines in the studio (they have to in order to do their work). That doesn't mean they should be able to copy other customer's data when I'm out for a minute to get us a coffee. So they must not be able to mount USB disks etc. I'm pretty sure there are many such cases in other environments. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, Oct 28, 2012 at 7:09 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
You (Tom) pointed out a way to disable logind modifying device ACLs recently. It could be a good thing to have that in the online docs for those users (like me) for whom this sort of thing is unwanted.
The rule that tags device nodes with the "uaccess" tag (which means they will be managed with ACL's) is 70-uaccess.rules[0]. 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. In most cases that's not the best solution, as you lose all the fast-user switching and multi-seat stuff, but it is useful to know. Hopefully the logind manpage will be updated soon to include a bit more info on these things.
Logind's behaviour seems to be based on two assumptions:
1. A non-local user (not near the system's HW) can't do anything useful with e.g. audio interfaces.
Not really. Logind does not at all manage non-local users, so if you want to give them access to your hardware you have to use another mechanism (such as groups).
2. A local user (having access to the system's HW) can do whatever evil he wants so there's no point in taking away any permissions.
Not really. This is indeed the default behaviour, but it is set up so that you can easily restrict it (and you should if you have a multi-seat computer): a user is given all the permissions to the hardware (as specified in 70-uacces.rules) on his/her seat. By default all hardware is assigned to seat0 and the user is assigned to seat0 too, but you could easily assign some hardware to a different seat.
For (2), a local user can do whatever evil only if he has unlimited time and is not supervised. I routinely let clients login to the local machines in the studio (they have to in order to do their work). That doesn't mean they should be able to copy other customer's data when I'm out for a minute to get us a coffee. So they must not be able to mount USB disks etc.
logind does not allow mounting of USB disks, but your point still stands (udisks would probably allow it based on info from logind, or you could get the same sort of effect using a device that logind would allow you to access). -t [0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules>
Not really. Logind does not at all manage non-local users, so if you want to give them access to your hardware you have to use another mechanism (such as groups).
I'm trying to setup an Arch instalation with remote logins using LDAP and systemd and didn't have audio at all. So it because of this? There is no other way to give remote users access to audio without putting all of them on "audio" group? I would prefer a better way to deal with this. Well, I even tried to create a local user and didn't have audio too (ls -la /dev/snd didn't show extended permissions), but maybe something is wrong with my PAM setup (or even NSS). -- Thiago Kenji Okada <thiago.mast3r@gmail.com> PGP Key: EEC09705
On 10/29/12 at 12:00am, Tom Gundersen wrote:
On Sun, Oct 28, 2012 at 7:09 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
You (Tom) pointed out a way to disable logind modifying device ACLs recently. It could be a good thing to have that in the online docs for those users (like me) for whom this sort of thing is unwanted.
The rule that tags device nodes with the "uaccess" tag (which means they will be managed with ACL's) is 70-uaccess.rules[0]. 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.
In most cases that's not the best solution, as you lose all the fast-user switching and multi-seat stuff, but it is useful to know.
Hopefully the logind manpage will be updated soon to include a bit more info on these things.
Logind's behaviour seems to be based on two assumptions:
1. A non-local user (not near the system's HW) can't do anything useful with e.g. audio interfaces.
Not really. Logind does not at all manage non-local users, so if you want to give them access to your hardware you have to use another mechanism (such as groups).
2. A local user (having access to the system's HW) can do whatever evil he wants so there's no point in taking away any permissions.
Not really. This is indeed the default behaviour, but it is set up so that you can easily restrict it (and you should if you have a multi-seat computer): a user is given all the permissions to the hardware (as specified in 70-uacces.rules) on his/her seat. By default all hardware is assigned to seat0 and the user is assigned to seat0 too, but you could easily assign some hardware to a different seat.
For (2), a local user can do whatever evil only if he has unlimited time and is not supervised. I routinely let clients login to the local machines in the studio (they have to in order to do their work). That doesn't mean they should be able to copy other customer's data when I'm out for a minute to get us a coffee. So they must not be able to mount USB disks etc.
logind does not allow mounting of USB disks, but your point still stands (udisks would probably allow it based on info from logind, or you could get the same sort of effect using a device that logind would allow you to access).
-t
[0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules>
I have been following this thread extra closely since I had removed myself from the numerous unnecessary groups, yet didn't quite understand why. Looking over 70-uaccess.rules, it is all making sense now. I did run into one problem though. I sometimes use mplayer from the console. To do this, I have set mplayer up to use fbdev2. Previously (when in all those groups), I was able to do this with no problem. but after making these changes, I suddenly had to be root to use mplayer in framebuffer mode. I realized that this was because /dev/fb0 was not included in the 70-uaccess.rules. I am no expert in udev rules, but I have written a few for various things. This file was dead simple to understand, so I copied it over to /etc/udev/rules.d and added: # framebuffer SUBSYSTEM=="graphics", KERNEL=="fb0", TAG+="uaccess" So I guess I just want to know if this is what I was supposed to have done. Or are there reasons why this may not have been implemented in the first place? As far as I can tell, this seems no different than previously being in the video group. If this is not a good idea, why might this be? Any insight would be greatly appreciated. Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Mon, Oct 29, 2012 at 5:47 AM, Curtis Shimamoto < sugar.and.scruffy@gmail.com> wrote:
I did run into one problem though. I sometimes use mplayer from the console. To do this, I have set mplayer up to use fbdev2. Previously (when in all those groups), I was able to do this with no problem. but after making these changes, I suddenly had to be root to use mplayer in framebuffer mode.
I realized that this was because /dev/fb0 was not included in the 70-uaccess.rules. I am no expert in udev rules, but I have written a few for various things. This file was dead simple to understand, so I copied it over to /etc/udev/rules.d and added:
# framebuffer SUBSYSTEM=="graphics", KERNEL=="fb0", TAG+="uaccess"
I think it is better to add a file /etc/udev/rules.d/71-my-uaccess.rules with just the line you need to add, instead of copying the whole 70-uaccess.rules file. That way you still get the upgrades to the standard file. Note that the names of the files make no difference, other than the order of execution. Regards -- Rodrigo
On 10/29/12 at 12:46pm, Rodrigo Rivas wrote:
On Mon, Oct 29, 2012 at 5:47 AM, Curtis Shimamoto < sugar.and.scruffy@gmail.com> wrote:
I did run into one problem though. I sometimes use mplayer from the console. To do this, I have set mplayer up to use fbdev2. Previously (when in all those groups), I was able to do this with no problem. but after making these changes, I suddenly had to be root to use mplayer in framebuffer mode.
I realized that this was because /dev/fb0 was not included in the 70-uaccess.rules. I am no expert in udev rules, but I have written a few for various things. This file was dead simple to understand, so I copied it over to /etc/udev/rules.d and added:
# framebuffer SUBSYSTEM=="graphics", KERNEL=="fb0", TAG+="uaccess"
I think it is better to add a file /etc/udev/rules.d/71-my-uaccess.rules with just the line you need to add, instead of copying the whole 70-uaccess.rules file. That way you still get the upgrades to the standard file. Note that the names of the files make no difference, other than the order of execution.
Regards -- Rodrigo
Yes, this was mentioned to me in the forums as well. It is a much better idea. Thanks for confirming that this is what I should be doing. So far, I have not heard any mention of this being a bad idea, or a security concern. So I guess I will be sticking with it until I find reason to do otherwise. Thanks again for the input Rodrigo -- Curtis Shimamoto sugar.and.scruffy@gmail.com
So far, I have not heard any mention of this being a bad idea, or a security concern.
I much prefer the output of ls but the acl man page says that the acls update the filesystem permissions and vice versa, so I would expect that if the getfacl command shows rw for the users you have in the video group and nothing for others then the permission settings atleast are equivalent. Having said that, I cannot see how to show all users permissions logged in and out, such as multiple members of groups using getfacl, atleast on a quick test with my log file permissions anyway. Maybe there is no need to? -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On 10/29/12 at 12:46pm, Rodrigo Rivas wrote:
On Mon, Oct 29, 2012 at 5:47 AM, Curtis Shimamoto < sugar.and.scruffy@gmail.com> wrote:
I did run into one problem though. I sometimes use mplayer from the console. To do this, I have set mplayer up to use fbdev2. Previously (when in all those groups), I was able to do this with no problem. but after making these changes, I suddenly had to be root to use mplayer in framebuffer mode.
I realized that this was because /dev/fb0 was not included in the 70-uaccess.rules. I am no expert in udev rules, but I have written a few for various things. This file was dead simple to understand, so I copied it over to /etc/udev/rules.d and added:
# framebuffer SUBSYSTEM=="graphics", KERNEL=="fb0", TAG+="uaccess"
I think it is better to add a file /etc/udev/rules.d/71-my-uaccess.rules with just the line you need to add, instead of copying the whole 70-uaccess.rules file. That way you still get the upgrades to the standard file. Note that the names of the files make no difference, other than the order of execution.
Regards -- Rodrigo
One more thing I forgot to ask. Do I need to include the ACTION and ENV{MAJOR} stuff in my personal rule (71-my-uaccess.rule)? Namely: ACTION=="remove", GOTO="uaccess_end" ENV{MAJOR}=="", GOTO="uaccess_end" ... LABEL="uaccess_end" Because, honestly, I am not entirely sure what that does besides the obvious part of telling it where to proceed to. -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Mon, Oct 29, 2012 at 3:24 PM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
One more thing I forgot to ask. Do I need to include the ACTION and ENV{MAJOR} stuff in my personal rule (71-my-uaccess.rule)? Namely:
ACTION=="remove", GOTO="uaccess_end" ENV{MAJOR}=="", GOTO="uaccess_end" ... LABEL="uaccess_end"
Because, honestly, I am not entirely sure what that does besides the obvious part of telling it where to proceed to.
You should keep the GOTO/LABEL in. It makes sure the rule is ignored in case the device is being ignored, or in case the MAJOR is not set. -t
On 10/29/12 at 08:09pm, Tom Gundersen wrote:
On Mon, Oct 29, 2012 at 3:24 PM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
One more thing I forgot to ask. Do I need to include the ACTION and ENV{MAJOR} stuff in my personal rule (71-my-uaccess.rule)? Namely:
ACTION=="remove", GOTO="uaccess_end" ENV{MAJOR}=="", GOTO="uaccess_end" ... LABEL="uaccess_end"
Because, honestly, I am not entirely sure what that does besides the obvious part of telling it where to proceed to.
You should keep the GOTO/LABEL in. It makes sure the rule is ignored in case the device is being ignored, or in case the MAJOR is not set.
-t
Awesome! Thanks so much for the input everyone. I shall go forth with confidence in my new udev rule! -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On 29/10/12 01:17, Zeke Sulastin wrote:
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.
So does this mean that extending the use of pre-defined groups is deprecated at best, and horribly wrong at worst? I've got all my music mounted via binds to /mnt/music so mpd can access it without needing to be able to walk the entire filesystem, and I've then added mpd to the audio group so it can access those files. It then outputs to a Pulseaudio via the network hack on the wiki[1]. I haven't had any issues, but this is essentially a single-user machine so I don't need the fast user switching abilities. Though there's no reason why I couldn't create a 'music' group, and change the permissions accordingly, if that is the more "correct" way to do things. I'm also using groups to allow very restricted non-root system administration; for example, TeXLive is installed in /opt/texlive with root:texlive and 775 permissions. [1] https://wiki.archlinux.org/index.php/Music_Player_Daemon/Tips_and_Tricks#Loc...
On Sun, Oct 28, 2012 at 4:26 AM, Dave Morgan <davemorgan353@btinternet.com> wrote:
Hi,
The systemd wiki article says:
"Note: Adding your user to groups (optical, audio, scanner, ...) is not necessary with systemd. It might even break the wanted functionality if you do so."
What are the the technical reasons for group membership breaking functionality when using systemd?
-- Dave.
ConsoleKit implement these session-based ACLs before, and now logind does. It's not really related to systemd. The reason for avoiding the audio group is that it can break software mixing. Sound with fast user switching also won't work at all if users are in the audio group.
On Sun, Oct 28, 2012 at 11:30 AM, Daniel Micay <danielmicay@gmail.com> wrote:
On Sun, Oct 28, 2012 at 4:26 AM, Dave Morgan <davemorgan353@btinternet.com> wrote:
Hi,
The systemd wiki article says:
"Note: Adding your user to groups (optical, audio, scanner, ...) is not necessary with systemd. It might even break the wanted functionality if you do so."
What are the the technical reasons for group membership breaking functionality when using systemd?
-- Dave.
ConsoleKit implement these session-based ACLs before, and now logind does. It's not really related to systemd. The reason for avoiding the audio group is that it can break software mixing. Sound with fast user switching also won't work at all if users are in the audio group.
By the way, I've updated that section in the wiki.[1] It should be a lot clearer now. [1] https://wiki.archlinux.org/index.php/Systemd#Supplementary_information
participants (12)
-
Curtis Shimamoto
-
Daniel Micay
-
Dave Morgan
-
F.Gr.
-
Fons Adriaensen
-
Giorgio Lando
-
Kevin Chadwick
-
Robbie Smith
-
Rodrigo Rivas
-
Thiago Kenji Okada
-
Tom Gundersen
-
Zeke Sulastin