@yuwata do you have any comments on this approach, considering you did f5cdf95?

uh? this makes no sense. the problem is that regular users shouldn't own device nodes, because it gives them too many rights. they should get read and/or write access, but certainly not ownership

uh? this makes no sense. the problem is that regular users shouldn't own device nodes, because it gives them too many rights. they should get read and/or write access, but certainly not ownership

Why? What exactly can the user do, and why is it a problem?

I can primarily see that they can change permissions, though I can't see a problem with that. It rather sounds like something that might be intentionally set up this way.

Why? What exactly can the user do, and why is it a problem?

I can primarily see that they can change permissions, though I can't see a problem with that. It rather sounds like something that might be intentionally set up this way.

It's udev that manages permissions through groups, access modes, ACLs and labels. We should not delegate that kind of stuff do regular users, that's way too much. Read/write access is one thing. Ownership is quite something else.

(that said, I think given the backlash we probably should downgrade the issue a bit, i.e. accept such borked ownerships, warn loudly though to get people fix their stuff, and disable the ownership again in 2y or so)

It's udev that manages permissions through groups, access modes, ACLs and labels. We should not delegate that kind of stuff do regular users, that's way too much. Read/write access is one thing. Ownership is quite something else.

Sorry if I'm not seeing something here, but I still don't get it. Yeah, ownership is something else. Why is it a problem? Way too much what?

I'm obviously running setups like this, otherwise I wouldn't have put together this patch, if there's some gaping security hole that I'm not aware of I'd certainly like to rectify that. Of course I can do something else. But this is creating work out of thin air, and not just for me, for everyone with a setup like that. The next person will have the same question. And the next. And the next. Coincidentally, I searched my search engines of choice for "device nodes user ownership problem" and similar terms — nothing.

So how about this be the place where an explanation is provided?

users shouldn't be able to delegate access to other users. they shouldn't be able to make devices world writable and stuff. but all that they can if they own the device nodes. they can set acls, they can change access modes, they can change groups, and so on. And that's not something udev should be delegating to the users.

udev should delegate access, not ownership

users shouldn't be able to delegate access to other users. they shouldn't be able to make devices world writable and stuff. but all that they can if they own the device nodes. they can set acls, they can change access modes, they can change groups, and so on. And that's not something udev should be delegating to the users.

udev should delegate access, not ownership

There's two problems with this.

First, it doesn't explain at all why udev also refuses GROUP= with non-system groups. This kinda runs diametrically counter to your own argument that udev "manages permissions through groups, access modes, ACLs and labels." — it is now prevented from managing permissions through groups. From all the information available to me at this point, it seems this is plainly a bug/accident?

Second… what you're communicating right now is a decision that someone made, not an argument or reasoning behind that decision¹. "Users shouldn't." I'm not sure if we have some kind of communication breakdown here; what I'm processing from you is perfectly valid explanations of what effects this has, but not why those effects are undesirable.

What about a situation where users actually own devices that they attach in a multi-user/shared environment? We have an electronics lab, with lab PCs. But most of the debug accessories are either straight up owned or at least tagged to a specific person, yet often enough they stay attached to something for a few days while their owner goes home. People chgrping their dongles to give someone else access is… natural. The setup here might be a bit exotic with the embedded dongle zoo, but I can see this making sense with USB-sticks, audio interfaces, maybe bluetooth devices (ok BT is a world of its own and irrelevant here), … and probably 20 other things I would never think of.

So, again, I ask: why is this undesirable? The best guess I have is: are you trying to prevent people from breaking their systems?

¹ I will also note here that it is quite common for neurospicy people — which covers a lot of FOSS people — to flat out reject decisions whose reasoning they don't know or can't follow. (Yes this applies to me.)

So, again, I ask: why is this undesirable? The best guess I have is: are you trying to prevent people from breaking their systems?

My understanding is that there are several smaller motives:

1. Non-system users are a late boot concept. Especially with signed UKIs, they might not exist in the initrd. Similarly, if using a user directory like LDAP, they too are not available early at boot.
2. TAG=uaccess is a more modern, secure alternative which integrates well with multi-session/-seat concepts, and improves security by only granting access to active sessions
3. There should simply not be a need to assign non-system users/groups to a device. A system group usually does the trick just as well in cases where e.g. TAG=uaccess does not work (like SSH sessions)

What about a situation where users actually own devices that they attach in a multi-user/shared environment? We have an electronics lab, with lab PCs. But most of the debug accessories are either straight up owned or at least tagged to a specific person, yet often enough they stay attached to something for a few days while their owner goes home. People chgrping their dongles to give someone else access is… natural. The setup here might be a bit exotic with the embedded dongle zoo, but I can see this making sense with USB-sticks, audio interfaces, maybe bluetooth devices (ok BT is a world of its own and irrelevant here), … and probably 20 other things I would never think of.

The recommended way to do this is via group membership or via "uaccess" or "xaccess". for nothing of this kind people actually need full ownership of the device.

The security model systemd/udev/logind is follow on anything is to delegate what's necessary but not more. (I mean, this is generally how things work in IT security these days, this isn't a model specific to systemd). Moreover, we want clear ownership, i.e. which component manages what resources, so that trampling over each other is avoid. But handing out device node ownership conflicts with that, for the specific case of device node management: ownership is a mechanism for delegating access control entirely to some user, since hey then have the ability to chmod/cgroup/setfacl as they wish, but that's really not what we want here: we want access control to be managed by udev, and not in some weird way by both udev and the user because we pass complete ownership to them. Because that's a) just too much, more than necessary and b) creates this conflict of management, because one one hand udev will chmod/chown/chgroup/setfacl the thing, and on the other hand we gave ownership away, so that they user can do it.

On top of that there's also the lifetime issue: regular users are assumed to show up very late (unlike system users/groups) during boot. See https://systemd.io/UIDS-GIDS for details. That makes them really weird for ownership of devices, since devices generally appear during earliest boot. So you are writing rules there that are inherently racy. (I mean, they might not be in your local setup because you have them locally in /etc/passwd, but in the general case they are racy).

I hope this makes sense. if not, i am giving up.

Let's close this one, this PR is more likely to succeed:

#40612

So, again, I ask: why is this undesirable? The best guess I have is: are you trying to prevent people from breaking their systems?

My understanding is that there are several smaller motives:

Thanks! These actually make logical sense.

1. Non-system users are a late boot concept. Especially with signed UKIs, they might not exist in the initrd. Similarly, if using a user directory like LDAP, they too are not available early at boot.

Hmm. I'm a bit torn here; I do also get to administer LDAP/sssd setups, but they don't overlap with the systems with custom udev owner rules, those have only local users. I'm not sure addressing this issue warrants straight up forbidding non-system IDs in udev though, since the situations where it is racy are controllable. Neither LDAP nor custom udev rules appear out of thin air, it's some sysadmin setting up both of them. They already need to understand the limitations of their setup, if they can understand the likely-involved Kerberos and NFS, they can deal with sequencing requirements in udev. As an extremely simple approach, a udevadm trigger after network-online would solve most of their issues?

The angle I'm looking at this from is that 99% of Linux installations will be using purely local users and have secure boot disabled. Users can always make their setups arbitrarily complicated/broken and cause things to stop working. Simply documenting that condition X is required for Y to work is also an option, right?

2. TAG=uaccess is a more modern, secure alternative which integrates well with multi-session/-seat concepts, and improves security by only granting access to active sessions

Well, this works great as long as you're on a desktop. Neither embedded systems nor servers nor containers use the seat concept. And udev is a lower layer than seats, sessions and logins. As a network stack software engineer, I tend to be extremely careful about lower layers developing a dependency on a higher layer. There's sometimes no way around it, but it's generally the choice of absolute last resort.

(Just to check—servers and embedded systems are still in scope for systemd, right? Or are they supposed to switch to something else?)

3. There should simply not be a need to assign non-system users/groups to a device. A system group usually does the trick just as well in cases where e.g. TAG=uaccess does not work (like SSH sessions)

Are you aware that system group membership can only be assigned from LDAP/via sssd in limited circumstances? You need to have consistent gid numbers for them across all systems and put that gid number into LDAP and "overlay" the system group. (Basically it's not currently possible to reference system groups by name.) Unfortunately, this tends to stop working as soon as more than one Linux distribution is involved. We've run into this limitation with the libvirt group and are currently applying some pretty gnarly patches to sssd: SSSD/sssd#8246. AFAIK the sssd people are working on a long-term solution, but it's not there yet.

There's also the problem that tying this into system groups significantly complicates "real" multi-user setups. If you have 2 teams with a few users each, and team X should be able to access devices A,B,C while team Y should be able to access devices D,E,F - if you can't reference their existing groups, how do you do that? Do you create plugdevA and plugdevB groups locally on the system? Change the udev rules to set ACLs? Can those ACLs then reference non-system users/groups?

But either way, thanks for the insight! I see these issues are tricky.

[…] creates this conflict of management, because one one hand udev will chmod/chown/chgroup/setfacl the thing, and on the other hand we gave ownership away, so that they user can do it. […]

It's not like udev randomly decides to go off and set device ownership and permissions. They're set when specific events happen. And unless the udev rules are poorly written, udev shouldn't/wouldn't be touching ownership and permissions after initially creating some device node.

Let's close this one, this PR is more likely to succeed:

#40612

That PR doesn't achieve the goal of safeguarding against systems/distributions adding new groups which then clash with existing ones, possibly giving users unwanted access to devices. (Which is what I understood the [sole] intent of the original change to be.)