Mastodawn

@rose wooooh
Im testing that tonite

rose Apr 5

@[email protected] yay! let me know how it goes
depending on the distro you're using the test/vm stuff may be useful
I'll probably have published the Gentoo ebuild as well by then

@rose ill test on my gentoo desktop and on my alpine laptop

@rose do u have plans to support the uaccess mechanism with other sessions tracker than *logind, like turnstile btw ?

rose

looking at the turnstile repo, they explicitly say its not a seat tracker, so I dont think I can support them
optimally id prefer to just have that part out honestly, uaccess is kinda annoying

CC: @[email protected]

@rose @tisanae yea , turnstile doesnt care abt seats you have to be compatible with seatd not with turnstile :P

rose Apr 5

seatd doesn't function like elogind, elogind acts with ACLs (try getfacl /dev/dri/card0 if you're using elogind), which are set by the device manager (which is awful awful awful but whatever), seatd does it a different way by opening the device for the compositor and passing over the fd

CC: @[email protected]

@rose @tisanae ohh thats nicer isnt it

so like what would be the usecase for even supporting thibgs that arent elogind ? ( :ebassi: )

@rose I see

Is there any alternatives to it for making hid input devices work outside of just giving ur user permission manually ?

@tisanae @rose whats an hid kb

@fiore @rose kb ? Games controllers and graphics tablets are accessed through hid devices (and uinput ??)

@fiore @rose some audio mixer controllers too

@tisanae @rose i was asking what hid means im dumy

@tisanae @rose

a) have some process with higher privileges open it and send a file descriptor over (seatd approach)
b) add the user to an acl (elogind) or unix groups (traditional)

i personally think unix groups are fine and limiting user access to devices is the wrong way to go about it, as the proper thing to do would be to control which programs/processes are allowed to do $thing, not which users

@navi @tisanae @rose > as the proper thing to do would be to control which programs/processes are allowed to do $thing, not which users

SELinux adjacent speech.

But yeah I do think that is reasonable.

@lispi314 @tisanae @rose

selinux is almost what i want except it's too complex and weird

i want simpler selinux, so like, just unix groups / acls but for processes -- so access to a resource would depend on both the user's groups and the pre-process groups

humm Apr 5

@navi @tisanae @rose @lispi314 I never closely looked at selinux, and I’m almost sorry for suggesting this, but … isn’t the setgid bit what you want?

@humm @navi @tisanae @rose setgid is insufficiently granular.

@humm @tisanae @rose @lispi314

no, i want to be able to remove privileges from processes, not add them

e.g. say /dev/video0 requires the ‘webcam’ user group, and the ‘webcam’ process group, to open O_RDONLY

my user is in the webcam group, but idk, this random game i’m playing, isn’t on the webcam process group, so even though my user can open that file, if the game tried it’d fail with EACCESS

while we could have a camera or chatting app that is on the webcam group, so then it now can open /dev/video0 without issue

and a user that is not on the webcam group would not be able to open /dev/video0 at all, regardless of whatever process groups the programs run into

@navi @tisanae @humm @rose Which really sounds a lot like SELinux labels enforcement mode (rather than something like Apparmor).

Though I'm rather familiar with how user unfriendly that is to actually use.

@lispi314 @humm @rose

selinux would be the thing i wanted if they weren't so impossible to maintain and use as a normal non-sysadmin user

so i want selinux-lite, basically