[bug#56690] [PATCH] gnu: seatd-service-type: Should use seat group.

[muradm <mail@muradm.net>]

[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]


Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:

> Am Montag, dem 08.08.2022 um 21:50 +0300 schrieb muradm:
>> > Which user?  Closely related, who acquires resources provided 
>> > by
>> > @code{seatd}?  Just the greeter?  A regular user logging in?
>> > What access level is needed/provided?  Read access?  Write
>> > access?
>> While I understand what you are saying, for me user is fine, 
>> and I
>> can't come up with better description, as my eyes too blurred 
>> on
>> this subject. Anyway for now I specified it as "libseat user".
> I don't think this really aids us here – it instead lets us ask 
> who is
> a "libseat user".  Perhaps you want to specify "login managers" 
> like
> greetd or gdm/sddm/etc. explicitly here?  Also, (when) do 
> regular users
> have to be in the seat group?
There is no such specification as login manager or what ever. User 
is
any one/thing acquiring resources via seat management. It is 
perfectly
fine to run mingetty, login into bash and from command line start 
sway
that will use libseat to acquire video for instance. Who is user 
here?

There is also no display manager as it was before. Please see my
explanation to unmatched-paren: 
https://debbugs.gnu.org/cgi/bugreport.cgi?msg=46;bug=56690
What is sway in this usecase, it is not a user (like you or me),
it is not a display manager (as gdm, sddm etc.). It is just
application requiring video card (not only) resource, which
it instead of having exclusive root access, uses libseat to
acquire it in "seat managy" way. And greetd does/should not
care about seatd/libseat until it is not required to acquire
resources in "seat managy" way. Instead it is a greeter which
is totatly customizable, could be even a bash script or small
suckless-like application or else.

This is the point of seatd I suppose, to do one thing only
without enforcing on who should do what.

Thus, none of your proposals are suitable, and I can't come up
with something better than "seat management user" or "libseat
user". However in my opinion, the one who commits into such
setup, should be aware of what is seatd libseat and how, why to
interact with it.

>> > > +  (group seatd-group (default "seat"))
>> > > +  (existing-group? seatd-existing-group? (default #f))
>> > AFAIK this is not necessary.  accounts-service-type can 
>> > handle
>> > multiple eq? groups, so as long as you're careful with what 
>> > you put
>> > into group, you shouldn't get an error.
>> ok field removed
> Note ‘eq?’ groups here.  In other words, you should be able to 
> take a
> group (not just a group name) for the group field, sanitize the 
> field
> so that it will always be a group, and then use that group in 
> seatd-
> accounts (see the second option mentioned in
> <79341a82bf9cd5fc6c2227255095f3fe2927dcbe.camel@ist.tugraz.at>). 
> If
> for instance instead of seat, you wanted the video group, you 
> would
> have to take the one from %base-groups, rather than creating a 
> new one.
Sorry, but I'm not so proficient in english as you. I can only
speculate on what is written here. And that reference does not
say anything to me, even duck duck go gives single result, it is
your message. Could you please be more specific here, and/or
provide more useful hyperlink style references. Thanks in advance.

> Cheers


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]