Mastodawn

Gentoo ebuilds are now available in https://git.pinkro.se/Rose/gardenhouse/ebuilds.git

ebuilds.git - Ebuilds for various Gardenhouse components

@rose wooooh
Im testing that tonite

@[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 ?

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

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

is the crw-rw---- from a boot with eudev or gardendevd?
eudev/systemd-udev perserve device permissions, while mdevd/gardendevd change all of them to 0660, so if /dev/media* was created by the kernel with 0666, eudev maintained it, while gardendevd changed it to 0660

Gato de muchos frijoles

@rose @fiore im gonna need you to package something while you're having dinner with maila's family im sure they will appreciate that

@coolbean @rose TOMORROW ILL DO IT

Laurent Bercot Apr 5

@rose real question, what was wrong with mdevd + libudev-zero that you needed to reimplement the full mechanism? Are there hooks I could add to mdevd that would make it usable as a device manager (without the libudev layer, of course) in more cases than it currently is?

Apart from support for systemd-udevs rule files, systemd-udev maintains a database of a bunch of device data in /run/udev, the main thing that gardendev does is process udev rules and populate the database

The one thing that I think would make mdevd more suited for desktop use is more advanced options in configs, but I'm not sure if things like uaccess are something you want to add, they're kinda messy designs

Laurent Bercot Apr 5

@rose not sure what uaccess is, but it seems to me that anything you'd need to add could be achieved via program execution lines in mdev.conf. That's what mdev-like-a-boss does.

Every systemd-udev rule bulitin would have to be implemented as its own executable, which is definetly possible, but with having to populate a database either way I felt like having it all in one daemon would be (for now) a better solution

@rose @ska

this feels oddly familiar to mdev vs mdevd =w=

what do you mean?

CC: @[email protected]

@rose @ska

as far as i know, mdev from busybox would register itself to handle events, and get spawned by the kernel on every event, then have to load it's config file and handle the event, every time

while mdevd uses the same config, but is a daemon and avoids a pretty massive overhead

or so i have been told

@rose @ska

it would probably matter way less to a "stateless" gardendev that is just executables, since if we can port all .rules to be mdev executions, then we don't have to load configs every time, though

oh, yes, if it'd be executables they definetly would have to be stateless, loading configs for every call would be annoying

CC: @[email protected] @[email protected]

Laurent Bercot Apr 5

@rose @navi yes, the problem with mdev hotplug invocations was

no synchronization mechanism, so no guaranteed ordering unless you manually used the sequencing feature for that, which had its own issue (I don't remember but I think it was busylooping or something)
parsing the config file for every event

mdevd solves these aspects, and spawning an additional helper for every (or most) uevent isn't prohibitively expensive thanks to posix_spawn()

@ska @rose doesn't help that libudev-zero was also full of stubs

that one can't really implement without the whole database and tag tracking of udev (and now of gardendev too)

yeah, in the long run I'd like to have gardendev only populate a database for libudev-zero, while mdevd is what handles the configs
I have a udev to mdev config translator tool as part of gardendev, but havent had the chance to test it yet

CC: @[email protected]