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 Apr 5

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

@humm @rose inb4 new @navi project

@rose its alive :3 !!!
https://codeberg.org/Topoetry/wip-aports/src/branch/master/testing/gardendevd/APKBUILD

wireplumber complains about /dev/media1 and /dev/media0 access and refuses to start :c

@[email protected] yay!!
I'll have to check how media is handled
it may need a change in the mdevd config

@[email protected] nvm it's a uaccess thing
can you try adding the following line to 70-camera.rules
SUBSYSTEM=="media", TAG+="uaccess"

https://git.pinkro.se/Rose/gardenhouse/gardendevd.git/commit/?id=5546adff8db74fedc557b6e86b7d5f5ed9ef03a9

this should technically fix your issue

CC: @[email protected]

gardendevd.git - Unnamed repository; edit this file 'description' to name the repository.

@rose huh, it is uaccess ? but how is it working with eudev then, i don't have elogind installed
Testing soon im waking

oh i see
eudev doesn't have uaccess lol
is your user in the video group? and can you show me the output of ls -alh /dev/media0

@rose aye ! it says crw-rw---- 1 root video 237, 0 Apr 6 14:42 /dev/media0

and you are in the video group?

@rose nope

okay that's your issue then
I assume eudev sets it to 0666, which is why you were able to access it, with gardendev its 0660, so youd have to be in the video group

in 50-udev-default.rules, you can also change the
SUBSYSTEM=="media", GROUP="video" line to SUBSYSTEM=="media", GROUP="video", MODE="0666" if you dont want to add your user to the video group

CC: @[email protected]

@rose but how is it working with only SUBSYSTEM=="media", GROUP="video" with eudev, is this an internal eudev thing ?

@rose wait lol, i never did read the logs with with eudev, wireplumber has the same complaints but still starts

wait huh so it just doesn't start anymore? thats gardenphobic wtf....

CC: @[email protected]

@rose oh, actully it starts but i only have the dummy device

okay okay, as root run
gardendevctl trigger
mdevd-coldplug
gardendevctl trigger
and then check again

@rose still only a dummy device

And another tengential issue, dhcpcd can't find the interfaces at boot but find them fine it restarted later

mmm probably something with libudev then, i'll look into it

@[email protected] I pushed a fix to gardendevd and libudev-zero, haven't had the chance to test it though, if you want to you can try it

@rose neat, lets get testing