udev set 640 permissions make no sense on device nodes

[lool]

Hi

I tried gaining access to the /dev/fastrpc nodes by adding my user to the fastrpc group, but that didn't help because the mode is 640. I think the mode should be 660.

It might also be best to have the udev and systemd service files directly in fastrpc upstream.

[ekanshibu]

What request was failing for you with 640? Did it help moving to 660?

We have already brought in systemd services to upstream.

For udev, I would prefer bringing it once the discussion over here is concluded.

[lool]

What request was failing for you with 640? Did it help moving to 660?

It did not help, fastrpc + AI workloads were working on a host, then I was trying to run some other AI workload as a container instead, which didn't work and I wondered if this was a permission issue with /dev/fastrpc, so I tried passing an extra group.

I guess either fastrpc daemons are the only ones that will ever open these device nodes readwrite, and then they could be group nobody, or some other userspace needs to open these device nodes readwrite, and then the perms should be 660 for the fastrpc group to mean anything.

We have already brought in systemd services to upstream.

Cool!

For udev, I would prefer bringing it once the discussion over here is concluded.

I'll comment there, but I think you can make this configurable for now. We briefly discussed this issue internally with Dmitry, Nico and others, and conclusion was leaning towards my position with a long-term plan to move to render/accel, but that would be with other device nodes.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. To prevent automatic closure in 10 days, remove the stale label or add a comment. You can reopen a closed issue at any time.

[lool]

So IIUC, the permissions are needed when 1) we're relying on apps talking to /dev/fastrpc directly rather than through the daemon, 2) we're relying on regular unix permissions rather than e.g. facls

I thin 660 is the right mode all the time, as also discussed in #16