I apologize for mentioning systemd. What non-deprecated group would be best for a "hardware user"? On Mon Jan 05 2015 at 12:23:22 PM Daniel Micay wrote:

On 05/01/15 02:12 PM, Neale Pickett wrote:

...

I feel like this notion ought to be part of the base install, even though systemd appears to have reworked how Unix device access is controlled.

It didn't change this. ConsoleKit used a similar model for sessions and also set ACLs on devices for the active local session. You're making it seem as if this is something recent but it has been this way for years.

https://wiki.archlinux.org/index.php/users_and_groups#Deprecated_or_unused_g... On Mon Jan 05 2015 at 12:29:39 PM Daniel Micay wrote:

On 05/01/15 02:24 PM, Neale Pickett wrote:

...

I apologize for mentioning systemd.

What non-deprecated group would be best for a "hardware user"?

Who is telling you that the groups in base are deprecated?

All right. Can someone then comment on which groups are actually deprecated, and which are not? I would like to not leave users with a broken system when the filesystem package is updated. On Mon Jan 05 2015 at 12:36:08 PM Daniel Micay wrote:

On 05/01/15 02:30 PM, Neale Pickett wrote:

...

https://wiki.archlinux.org/index.php/users_and_groups# Deprecated_or_unused_groups

The groups have been replaced / deprecated as a way of giving hardware access to users with local sessions. That doesn't mean that they're deprecated as a whole or that they'll go away. It's possible, but you can't determine that from opinions on a wiki.

This is very helpful. Thank you! On Mon Jan 05 2015 at 2:06:50 PM Leonid Isaev wrote:

On Mon, Jan 05, 2015 at 07:12:41PM +0000, Neale Pickett wrote:

...

I run mdev instead of systemd-udev and was just alerted to the deprecation of all the groups I'd been using. Looking at the filesystem package, it seems that most of them are still present, but I presume they'll go away eventually.

In general... The groups you are talking about (i.e. optical, etc.) are arbitrary to begin with, so there is no strict requirement for having them. On a (current) Arch system your user doesn't need to be in any of these groups, so you can manually delete them. The reason is, as you said, that logind grants device access to local users. Of course, this logic won't work if you'd like to e.g. play audio over ssh (you'll have to be a member of audio).

Regarding the "standard" group list, I'd do the following: (1) Look at /usr/lib/sysuser.d/*. This is the systemd way (tm) of defining "standard" groups. The filesystem .install script follows this convention, AFAIK. So, these groups are unlikely to be deprecated in Arch, unless they are also deprecated in systemd (which might happen on a whim of course). (2) Clone Arch SVN repos and grep the .install scripts for udev rules that set device permissions to the above groups. I don't think there will be many (lvm2 and device-mapper come to mind).

If in (2) no packages come up, then just ignore Arch default groups (in the filesystem package). You already run a non-standard udev (mdev), so you'll have to make sure that the device nodes are created with a correct u+g permissions (via some rules). These rules will define your "standard" group list. Otherwise, stick with systemd groups.

HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

I'm not going to remove any groups, but I want to make sure I'm not configuring mdev to set ownership to a group that may not exist in the future. I will probably create a new group called "hardware" that will allow users to access audio, video, serial, and USB storage devices, and use Posix ACLs to set individual permissions for daemons like mpd. Things that are packaged now should continue to work (or not) as normal with Arch's default filesystem groups if they're using my mdev/runit setup. I do have systemd installed. Too many things depend on it for me to remove it. If I could remove or recompile X11, tcpdump (libusb), nfs-utils (device-mapper), and procps-ng, I think I might be able to remove the systemd package. But I have enough work already, I don't need to go recompiling stuff just to get rid a single dependency! :) On Mon Jan 05 2015 at 3:47:37 PM Leonid Isaev wrote:

On Mon, Jan 05, 2015 at 09:59:51PM +0000, Neale Pickett wrote:

...

This is very helpful. Thank you!

If you go with your own group list, check configs of your daemons to see which groups they expect. Some (e.g. dnsmasq) will call useradd and groupadd in their .install files. But syslog-ng, for example, by default creates log files 640 root:log...

Also, I just wonder, do you have systemd installed at all?

Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Hello, im not sure how useful this advice is, but have you considered to ask on the archbsd mainlinglist? I dont know if they're using udev, mdev or another thing, but may they have some tips for that. regards, Am 2015-01-07 10:09, schrieb Tobias Hunger:

Hi Neale,

The packages in arch are built with the systemd security model in mind. You are changing that pretty fundamental assumption by ripping out systemd, logind & co. and that will have an effect on the overall security of your system. At least give the packages a chance to respond to that changed assumption by rebuilding them, telling them that there won't be any systemd. That way they can adapt their configuration and permissions during install (not that I think many will;-). Ideally you would also go through all PKGBUILDs with a fine toothed comb to find settings that need to be adapted from the arch-defaults before rebuilding.

Of course you also need to be aware of the security issues that were fixed by logind. This is mostly (remote) users being able to snoop on local users by recording keystrokes or even audio/video of them at the machine. People argue that this is not much of an issue on a single-user machine.

You also will need to run xorg as root, which is a huge piece of code known to be written before security was a concern to developers. Logind allows to run that as a normal user (provided other conditions are met as well).

TL;DR: Replacing systemd in arch is nothing that should be attempted in an idle afternoon.

Best Regards, Tobias

On Tue, Jan 6, 2015 at 12:42 AM, Neale Pickett wrote:

...

I'm not going to remove any groups, but I want to make sure I'm not configuring mdev to set ownership to a group that may not exist in the future. I will probably create a new group called "hardware" that will allow users to access audio, video, serial, and USB storage devices, and use Posix ACLs to set individual permissions for daemons like mpd. Things that are packaged now should continue to work (or not) as normal with Arch's default filesystem groups if they're using my mdev/runit setup.

I do have systemd installed. Too many things depend on it for me to remove it. If I could remove or recompile X11, tcpdump (libusb), nfs-utils (device-mapper), and procps-ng, I think I might be able to remove the systemd package. But I have enough work already, I don't need to go recompiling stuff just to get rid a single dependency! :)

On Mon Jan 05 2015 at 3:47:37 PM Leonid Isaev wrote:

...

On Mon, Jan 05, 2015 at 09:59:51PM +0000, Neale Pickett wrote:

...

This is very helpful. Thank you!

If you go with your own group list, check configs of your daemons to see which groups they expect. Some (e.g. dnsmasq) will call useradd and groupadd in their .install files. But syslog-ng, for example, by default creates log files 640 root:log...

Also, I just wonder, do you have systemd installed at all?

Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D