guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: muradm
Subject: [bug#56690] [PATCH] gnu: seatd-service-type: Should use seat group.
Date: Tue, 09 Aug 2022 22:47:01 +0300
User-agent: mu4e 1.8.7; emacs 29.0.50


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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]