seatd ebuild bug? seat or video ownership

[mv]

Hi,

I am writing, because I observed a strange thing in the sys-auth/seatd ebuild:

It installs /etc/init.d/seatd which effectively calls

[mv]

To answer my own question: According to the discussion preceediing that post, it is probably not a good idea anymore to put any user (besides a login manager) in the video group - this ~20 years old recommendation is probably not valid anymore in the times of wayland.
So it seems to me that seat is the correct group and that the video group in the openrc startup script is the wrong choice.

I checked that if moving the user from the video to the seat group (and changing the openrc script) works.

Note that there is a bug filed, meanwhile.

[Anon-E-moose]

The video group should be accurate because that's the group for the video card (set by *udev)

[Zucca]

Oh boy. I wonder how many guides at the wiki tells people to add their user to video group.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[Anon-E-moose]

I'm not sure that end user has to be in the video group, as long as seatd is.

Seatd is just doing things on behalf of the end user, ie video related stuff, along with input, etc.

I remember a time in graphic computing when you needed to be in certain groups or your system wouldn't work
things change over time, and usually things like wiki's are at the bottom of the pile on updating properly.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[mv]

[Anon-E-moose]

[CooSee]

output of sway with seatd:

[mv]

[CooSee]

[Anon-E-moose]

Seatd needs "-g video" so that it runs in the video group and can handle drm master operations on behalf of the user.
Seatd should be started by /etc/init.d for openrc, not sure about systemd.

The user does not need to be in the video group seatd takes care of that access.

Not sure why the ebuild pulls in acct-group/seat, it doesn't use it.

[GDH-gentoo]

seatd's -g option only controls who can connect to its UNIX domain socket, /run/seatd.sock, and therefore, who can interact with the daemon through libseat, i. e. call libseat_open_seat(), libseat_open_device(), etc.

seatd itself runs as root, so it has no problems with open() and ioctl() calls. Therefore, it does seem correct that the socket have group seat on OpenRC too.
_________________

[Anon-E-moose]

Now that I've slept and thought about it a little, you're right GDH.
I knew that seatd ran as root, it get started (on my system) by /etc/init.d/seatd, thus runs as root.

I just didn't think through completely on the -u -g options.

Then I agree, for security (small though it be) group seat is better.
Not that this keeps someone from being in the video group for other reasons.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[CooSee]

i switch to seatd as default, without removing elogind - just removed from boot startup.

Sway feels snappier - maybe just my imagination.


_________________
" Die Realität ist eine Illusion, die durch Mangel an ehrlicher Kommunikation entsteht "
---
" Der Mensch ist von Natur aus neugierig, was am Ende übrig bleibt ist die Gier "

[Redeeman]

sorry to somewhat go off on a tangent, but what is the permissions actually supposed to be on the renderD* devices?

i run a multiseat system, and I notice that the default permissions udev rules assign the renderD128 and renderD129 is as follows:
crw-rw----+ 1 root video 226, 0 Jun 21 10:57 card0
crw-rw----+ 1 root video 226, 1 Jun 21 10:10 card1
crw-rw-rw- 1 root render 226, 128 Apr 29 01:51 renderD128
crw-rw-rw- 1 root render 226, 129 Apr 29 01:51 renderD129

This doesnt seem right to me? Wouldnt it be appropriate for me to change it to 660, and then do the required dance to have the ACL for the actual seat user be added to the apropriate device (similar to with card devices) ?

[GDH-gentoo]