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

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

> Am Sonntag, dem 07.08.2022 um 23:05 +0300 schrieb muradm:
>
>> * gnu/services/desktop.scm (seatd-service-type): Uses "seat" 
>> group.
>> [extensions]: Added account-service-type with seatd-accounts.
>> (seatd-accounts): Conditionally produces list with "seat" 
>> group.
>> (<seatd-configuration>):
>> [user] Drop user field, since it is not going to be used.
> Removed field.
done

>> [group] Change default value to "seat".
>> [existing-group?] Add field which controls if group should be
>> created or not.
> Would be Added field, but see below.
obsolete

>> * doc/guix.texi: Mention that users may need to become members 
>> of
>> "seat" group and update default value for group field. Add
>> explanation on seatd.sock file. Remove dropped user field.
>
>> +When seat mamanagement is provided by @code{seatd}, users that
>> acquire
> management.
done

>> +resources provided by @code{seatd} should have permissions to 
>> access
>> +its UNIX domain socket. By default, @code{seatd-service-type}
>> provides
>> +``seat'' group. And user should become its member.
> 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".

>> +  (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

> Cheers

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?

> > > +  (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.

Cheers

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

Am Dienstag, dem 09.08.2022 um 22:47 +0300 schrieb muradm:
> 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.
I think you're mixing user and application here, which makes explaining
this to others difficult.  For instance, GDM is both an application
(display manager) and a user launching this application.  Likewise for
most other display managers.  Thus, there is a 1:1 mapping between
users and applications.

With seatd, from what I understand, there is no such mapping.  However,
given your description, the following is unclear: Does alice need to be
in the seat group to run bash?  To run sway?  To run sway *only if not
having talked to greetd first*?

> > > > > +  (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.
I'll explain it in terms of lisp:

(define seat1 (user-group (name "seat") (system #t))
(define seat2 (user-group (name "seat") (system #t))
(operating-system (groups (list seat1 seat1))) ; works, eq?
(operating-system (groups (list seat2 seat2))) ; works, eq?
(operating-system (groups (list seat1 seat2))) ; doesn't work

For field sanitizers, see define-record-type*.

Cheers

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

> Am Dienstag, dem 09.08.2022 um 22:47 +0300 schrieb muradm:
>> 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.
> I think you're mixing user and application here, which makes 
> explaining
> this to others difficult.  For instance, GDM is both an 
> application
> (display manager) and a user launching this application. 
> Likewise for
> most other display managers.  Thus, there is a 1:1 mapping 
> between
> users and applications.
I don't think that I miss, instead I intend to generalize as much
as possible. I suppose it is better to say, seat management can be
used by anyone or anything where greeter would be an example of
anything, and logged in user an example of anyone.

> With seatd, from what I understand, there is no such mapping. 
> However,
> given your description, the following is unclear:
> Does alice need to be in the seat group to run bash?
Alice needs to be in seat group if any application and/or
script is going to be using libseat for acquiring resources in
"seat managy" way, in order to have access to seatd.sock.

> To run sway?
Since sway is aciqyuring resources using libseat in "seat managy"
way, then Alice will have to be in seat group to access 
seatd.sock.

> To run sway *only if not having talked to greetd first*?
greetd is unrelated here, as greetd by it self is not acquiring
resources in "seat managy" way. Currently no greeter for greetd
also talks via libseat to seatd _directly_. But special case of
gtkgreet which requires wayland compositor, which is sway, creates
indirect relation of "seat managy" resources acquisiion using
libseat. This indirect relation requiring user of greeter to be
a member of seat group.

>> > > > > +  (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.
> I'll explain it in terms of lisp:
>
> (define seat1 (user-group (name "seat") (system #t))
> (define seat2 (user-group (name "seat") (system #t))
> (operating-system (groups (list seat1 seat1))) ; works, eq?
> (operating-system (groups (list seat2 seat2))) ; works, eq?
> (operating-system (groups (list seat1 seat2))) ; doesn't work
>
> For field sanitizers, see define-record-type*.
I know how eq? works. I don't understand what do you want me to
do with service configuration.

> Cheers