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

Done

Details

5 participants

Liliana Marie Prikler
Liliana Marie Prikler
Ludovic Courtès
muradm
(

Owner: unassigned

Submitted by: muradm

Severity: normal

muradm wrote on 22 Jul 2022 06:27

Recipients:(address . guix-patches@gnu.org)

Message-ID:20220722042745.26745-1-mail@muradm.net

* gnu/services/desktop.scm (seatd-service-type): Uses "seat" group.
[extensions]: Added account-service-type with %seatd-accounts.
(%seatd-accounts): List with "seat" group.
(<seatd-configuration>): [group] Change default value to "seat".
* doc/guix.texi: Mention that users may need to become members of
"seat" group and update default value for group field.
---
 doc/guix.texi            | 18 +++++++++++++++++-
 gnu/services/desktop.scm |  8 ++++++--
 2 files changed, 23 insertions(+), 3 deletions(-)

Toggle diff (78 lines)diff --git a/doc/guix.texi b/doc/guix.texi
index 3c5864ec1a..750ed9b121 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -23151,6 +23151,22 @@ input), without requiring the applications needing access to be root.
   %base-services)
 
 @end lisp
+
+Users which are going to interact with @code{seatd} daemon while logged in
+should be added to @code{seat} group. For instance:
+
+@lisp
+(user-account
+  (name "alice")
+  (group "users")
+  (supplementary-groups '("wheel"   ;allow use of sudo, etc.
+                          "seat"    ;interact with seatd
+                          "audio"   ;sound card
+                          "video"   ;video devices such as webcams
+                          "cdrom")) ;the good ol' CD-ROM
+  (comment "Bob's sister"))
+@end lisp
+
 @end defvr
 
 @deftp {Data Type} seatd-configuration
@@ -23163,7 +23179,7 @@ The seatd package to use.
 @item @code{user} (default: @samp{"root"})
 User to own the seatd socket.
 
-@item @code{group} (default: @samp{"users"})
+@item @code{group} (default: @samp{"seat"})
 Group to own the seatd socket.
 
 @item @code{socket} (default: @samp{"/run/seatd.sock"})
diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index 29a3722f1b..0d7cd71732 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -13,7 +13,7 @@
 ;;; Copyright © 2020 Tobias Geerinckx-Rice <me@tobias.gr>
 ;;; Copyright © 2020 Reza Alizadeh Majd <r.majd@pantherx.org>
 ;;; Copyright © 2021 Brice Waegeneire <brice@waegenei.re>
-;;; Copyright © 2021 muradm <mail@muradm.net>
+;;; Copyright © 2021, 2022 muradm <mail@muradm.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1646,7 +1646,7 @@ (define-record-type* <seatd-configuration> seatd-configuration
   seatd-configuration?
   (seatd seatd-package (default seatd))
   (user seatd-user (default "root"))
-  (group seatd-group (default "users"))
+  (group seatd-group (default "seat"))
   (socket seatd-socket (default "/run/seatd.sock"))
   (logfile seatd-logfile (default "/var/log/seatd.log"))
   (loglevel seatd-loglevel (default "info")))
@@ -1670,6 +1670,9 @@ (define (seatd-shepherd-service config)
                    #:log-file #$(seatd-logfile config)))
          (stop #~(make-kill-destructor)))))
 
+(define %seatd-accounts
+  (list (user-group (name "seat") (system? #t))))
+
 (define seatd-environment
   (match-lambda
     (($ <seatd-configuration> _ _ _ socket)
@@ -1683,6 +1686,7 @@ (define seatd-service-type
 applications needing access to be root.")
    (extensions
     (list
+     (service-extension account-service-type (const %seatd-accounts))
      (service-extension session-environment-service-type seatd-environment)
      ;; TODO: once cgroups is separate dependency we should not mount it here
      ;; for now it is mounted here, because elogind mounts it
-- 
2.36.1

(

( wrote on 24 Jul 2022 18:28

Recipients:

Message-ID:CLO115738RZH.2Q7DHDC619VG6@guix-aspire

Because patches with replies are more likely to be visible: LGTM :)

-- (

Liliana Marie Prikler wrote on 4 Aug 2022 13:08

Re: greeter user permissions are not enough to talk with seatd

Recipients:(address . control@debbugs.gnu.org)

Message-ID:b5687a1a3eebc0cce2564634bc4e191cf7abd931.camel@ist.tugraz.at

block 56971 by 56690 56699

thanks

Hi muradm,

Am Donnerstag, dem 04.08.2022 um 12:45 +0300 schrieb muradm:

Toggle quote (9 lines)> [...] greeter (e.g. gtkgreet) requiring communication
> with seatd is failing to start, causing "black screen"
> behavior on active terminal (switching to the other non seatd
> related terminal is possible, for manual permissions
> adjustment as workaround).
> 
> To address this issue, we need more flexible control over
> seatd user/group, which creates seatd.sock, and greeter user
> which connects to seatd.sock.

Okay.

Toggle quote (2 lines)

> However, not all greeters require that, so I decided to make

> more flexible.

Flexibility for its own sake is not always the right solution. On the

other hand, looking at the two patches, it appears they are to be used

in combination?

Toggle quote (7 lines)>  Propsed solutions consists of:
> 
> * 56690 - gnu: seatd-service-type: Should use seat group.
> With this change, if seatd-service-type is present in the
> system configuration, "seat" group will be added, and seatd
> will run as root/seat. Group is configurable, but default is 
> "seat".

Why just the group and no user? Is it not possible to launch seatd as

non-root?

Toggle quote (5 lines)> * 56699 - gnu: greetd-service-type: Add greeter-extra-groups 
> � config field.
> With this change, if user wants to use seatd-service-type with
> greeter requiring seatd.sock, he can add "seat" group to
> greeter-extra-groups field.

Note that you still have a TODO on that patch.

Cheers

Liliana Marie Prikler wrote on 5 Aug 2022 10:10

Re: [PATCH] gnu: seatd-service-type: Should use seat group.

Recipients:

Message-ID:79341a82bf9cd5fc6c2227255095f3fe2927dcbe.camel@ist.tugraz.at

Am Freitag, dem 22.07.2022 um 07:27 +0300 schrieb muradm:

Toggle quote (6 lines)> * gnu/services/desktop.scm (seatd-service-type): Uses "seat" group.
> [extensions]: Added account-service-type with %seatd-accounts.
> (%seatd-accounts): List with "seat" group.
> (<seatd-configuration>): [group] Change default value to "seat".
> * doc/guix.texi: Mention that users may need to become members of
> "seat" group and update default value for group field.

Note, that your current patch adds a little asymmetry.  Even if you
configure seatd to use a group different from seat, a (now useless)
seat group will be created.

There are (at least) two possible fixes for this:
1. Disable configuration for the group altogether, marking the field as
deprecated.
2. Change the field into one that accepts a group.  Also sanitize the
field so that if a string such as "seat" is provided, it is turned into
a group.  Then make seatd-accounts return this group.

Cheers

Ludovic Courtès wrote on 6 Aug 2022 22:46

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

Recipients:(name . muradm)(address . mail@muradm.net)(address . 56690@debbugs.gnu.org)

Message-ID:87czdddrra.fsf@gnu.org

Hi,

muradm <mail@muradm.net> skribis:

Toggle quote (7 lines)

> * gnu/services/desktop.scm (seatd-service-type): Uses "seat" group.

> [extensions]: Added account-service-type with %seatd-accounts.

> (%seatd-accounts): List with "seat" group.

> (<seatd-configuration>): [group] Change default value to "seat".

> * doc/guix.texi: Mention that users may need to become members of

> "seat" group and update default value for group field.

I guess I’m missing some context: is this fixing a bug currently

present? (Apologies if this has been discussed elsewhere!)

Toggle quote (2 lines)

> +Users which are going to interact with @code{seatd} daemon while logged in

s/which/who/

Toggle quote (13 lines)> +should be added to @code{seat} group. For instance:
> +
> +@lisp
> +(user-account
> +  (name "alice")
> +  (group "users")
> +  (supplementary-groups '("wheel"   ;allow use of sudo, etc.
> +                          "seat"    ;interact with seatd
> +                          "audio"   ;sound card
> +                          "video"   ;video devices such as webcams
> +                          "cdrom")) ;the good ol' CD-ROM
> +  (comment "Bob's sister"))

The problem I see with this extra doc is that even I wouldn’t know how

to tell whether I’m going to “interact with seatd”. Fundamentally it’s

not something I really care about. :-)

How could we improve on this? Like, if this is important, should it be

the default?

Thanks,

Ludo’.

(

( wrote on 6 Aug 2022 22:50

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

Recipients:(address . 56690@debbugs.gnu.org)

Message-ID:CLZ8QMN65YQ3.2YI4TMHBJ5MB9@guix-aspire

On Sat Aug 6, 2022 at 9:46 PM BST, Ludovic Courtès wrote:

Toggle quote (3 lines)

> I guess I’m missing some context: is this fixing a bug currently

> present? (Apologies if this has been discussed elsewhere!)

This is one of two patches that fix a problem where any greetd greeter

more complex than agreety hangs on boot, basically rendering greetd

useless. I think the underlying cause is their being unable to connect

to seatd.sock?

At least, that's the symptom I know about. I'm not sure whether there

are others.

-- (

muradm wrote on 7 Aug 2022 19:28

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

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 56690@debbugs.gnu.org)

Message-ID:87les00x51.fsf@muradm.net

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (18 lines)> Hi,
>
> muradm <mail@muradm.net> skribis:
>
>> * gnu/services/desktop.scm (seatd-service-type): Uses "seat" 
>> group.
>> [extensions]: Added account-service-type with %seatd-accounts.
>> (%seatd-accounts): List with "seat" group.
>> (<seatd-configuration>): [group] Change default value to 
>> "seat".
>> * doc/guix.texi: Mention that users may need to become members 
>> of
>> "seat" group and update default value for group field.
>
> I guess I’m missing some context: is this fixing a bug currently
> present?  (Apologies if this has been discussed elsewhere!)
>

Not really a bug, but misconfiguration i suppose. Started here

with

commit about month or two ago:

https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00021.html

Basically, with original configuration, greeter was in the wheel

group

which allowed it to communicate with seatd over /run/seatd.sock.

Toggle quote (6 lines)

>> +Users which are going to interact with @code{seatd} daemon

>> while logged in

> s/which/who/

With above fix, wheel and other groups were removed. While it was 
not
affecting default greeter agretty, some people including me, use
graphical greeter gtkgreet or others based on sway. Then sway with
greeter started by greetd needs to communicate with seatd. Due to
the fact of missing permission, greeter just dies with blank 
screen.

So "users which are going to interact" basically users who want
to run sway, or anything else requiring libseat based seat 
management
present.

Toggle quote (25 lines)>> +should be added to @code{seat} group. For instance:
>> +
>> +@lisp
>> +(user-account
>> +  (name "alice")
>> +  (group "users")
>> +  (supplementary-groups '("wheel"   ;allow use of sudo, etc.
>> +                          "seat"    ;interact with seatd
>> +                          "audio"   ;sound card
>> +                          "video"   ;video devices such as 
>> webcams
>> +                          "cdrom")) ;the good ol' CD-ROM
>> +  (comment "Bob's sister"))
>
> The problem I see with this extra doc is that even I wouldn’t 
> know how
> to tell whether I’m going to “interact with seatd”. 
> Fundamentally it’s
> not something I really care about.  :-)
>
> How could we improve on this?  Like, if this is important, 
> should it be
> the default?
>

Two options, a) users who want greetd/seatd setup normally 
advanced
users wishing to get away from systemd/logind/dbus world, so they
probably was to be aware of what is going on; b) copy a piece of
documentation from seatd, explaining seatd.sock maybe. Other than
that I could ask the same question about video, audio etc. groups 
:)

Toggle quote (2 lines)

> Thanks,

> Ludo’.

muradm wrote on 7 Aug 2022 22:05

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

Recipients:

Message-ID:87h72n24ra.fsf@muradm.net

here is updated patch:
- group is now correctly configurable
- dropped user field as it is mostlikely pointless
- group is created if necessary
- documentation updated adding mentioning of seatd.sock 
  permissions
- adding test case for seatd.sock ownership

thanks in advance,
muradm

Attachment: v2-0001-gnu-seatd-service-type-Should-use-seat-group.patch

muradm <mail@muradm.net> writes:

Toggle quote (99 lines)> [[PGP Signed Part:Undecided]]
>
> Hi,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi,
>>
>> muradm <mail@muradm.net> skribis:
>>
>>> * gnu/services/desktop.scm (seatd-service-type): Uses "seat" 
>>> group.
>>> [extensions]: Added account-service-type with %seatd-accounts.
>>> (%seatd-accounts): List with "seat" group.
>>> (<seatd-configuration>): [group] Change default value to 
>>> "seat".
>>> * doc/guix.texi: Mention that users may need to become members 
>>> of
>>> "seat" group and update default value for group field.
>>
>> I guess I’m missing some context: is this fixing a bug 
>> currently
>> present?  (Apologies if this has been discussed elsewhere!)
>>
>
> Not really a bug, but misconfiguration i suppose. Started here 
> with
> commit about month or two ago:
>
> https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00021.html
>
> Basically, with original configuration, greeter was in the wheel 
> group
> which allowed it to communicate with seatd over /run/seatd.sock.
>
>>> +Users which are going to interact with @code{seatd} daemon 
>>> while
>>> logged in
>>
>> s/which/who/
>>
>
> With above fix, wheel and other groups were removed. While it 
> was not
> affecting default greeter agretty, some people including me, use
> graphical greeter gtkgreet or others based on sway. Then sway 
> with
> greeter started by greetd needs to communicate with seatd. Due 
> to
> the fact of missing permission, greeter just dies with blank 
> screen.
>
> So "users which are going to interact" basically users who want
> to run sway, or anything else requiring libseat based seat 
> management
> present.
>
>>> +should be added to @code{seat} group. For instance:
>>> +
>>> +@lisp
>>> +(user-account
>>> +  (name "alice")
>>> +  (group "users")
>>> +  (supplementary-groups '("wheel"   ;allow use of sudo, etc.
>>> +                          "seat"    ;interact with seatd
>>> +                          "audio"   ;sound card
>>> +                          "video"   ;video devices such as 
>>> webcams
>>> +                          "cdrom")) ;the good ol' CD-ROM
>>> +  (comment "Bob's sister"))
>>
>> The problem I see with this extra doc is that even I wouldn’t 
>> know
>> how
>> to tell whether I’m going to “interact with seatd”. 
>> Fundamentally
>> it’s
>> not something I really care about.  :-)
>>
>> How could we improve on this?  Like, if this is important, 
>> should it
>> be
>> the default?
>>
>
> Two options, a) users who want greetd/seatd setup normally 
> advanced
> users wishing to get away from systemd/logind/dbus world, so 
> they
> probably was to be aware of what is going on; b) copy a piece of
> documentation from seatd, explaining seatd.sock maybe. Other 
> than
> that I could ask the same question about video, audio etc. 
> groups :)
>
>> Thanks,
>> Ludo’.
>
> [[End of PGP Signed Part]]

muradm wrote on 7 Aug 2022 22:45

Re: [PATCH] gnu: seatd-service-type: Should use seat group.

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 56690@debbugs.gnu.org)

Message-ID:87czdb235b.fsf@muradm.net

Fixed in v2.

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

Toggle quote (27 lines)> Am Freitag, dem 22.07.2022 um 07:27 +0300 schrieb muradm:
>> * gnu/services/desktop.scm (seatd-service-type): Uses "seat" 
>> group.
>> [extensions]: Added account-service-type with %seatd-accounts.
>> (%seatd-accounts): List with "seat" group.
>> (<seatd-configuration>): [group] Change default value to 
>> "seat".
>> * doc/guix.texi: Mention that users may need to become members 
>> of
>> "seat" group and update default value for group field.
> Note, that your current patch adds a little asymmetry.  Even if 
> you
> configure seatd to use a group different from seat, a (now 
> useless)
> seat group will be created.
>
> There are (at least) two possible fixes for this:
> 1. Disable configuration for the group altogether, marking the 
> field as
> deprecated.
> 2. Change the field into one that accepts a group.  Also 
> sanitize the
> field so that if a string such as "seat" is provided, it is 
> turned into
> a group.  Then make seatd-accounts return this group.
>
> Cheers

Liliana Marie Prikler wrote on 8 Aug 2022 08:08

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

Recipients:

Message-ID:55a3a3bf118f364b70cbd74d214998955d81eaa9.camel@ist.tugraz.at

Am Sonntag, dem 07.08.2022 um 23:05 +0300 schrieb muradm:

Toggle quote (5 lines)> * 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.

Toggle quote (3 lines)

> [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.

Toggle quote (6 lines)

> * 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.

Toggle quote (4 lines)

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

Toggle quote (2 lines)

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

Cheers

Ludovic Courtès wrote on 8 Aug 2022 10:58

Recipients:(name . ()(address . paren@disroot.org)

Message-ID:87sfm7az76.fsf@gnu.org

Hi,

"(" <paren@disroot.org> skribis:

Toggle quote (12 lines)> On Sat Aug 6, 2022 at 9:46 PM BST, Ludovic Courtès wrote:
>> I guess I’m missing some context: is this fixing a bug currently
>> present?  (Apologies if this has been discussed elsewhere!)
>
> This is one of two patches that fix a problem where any greetd greeter
> more complex than agreety hangs on boot, basically rendering greetd
> useless. I think the underlying cause is their being unable to connect
> to seatd.sock?
>
> At least, that's the symptom I know about. I'm not sure whether there
> are others.

Is there a bug report, and do we have system tests for this

functionality?

I admit I know little about greetd and cases where it might be used.

Having system tests for that would help make sure the relevant

functionality works.

Thanks,

Ludo’.

(

( wrote on 8 Aug 2022 11:12

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:CM0J5LA0SDT1.29QEUPBP5V7JK@guix-aspire

On Mon Aug 8, 2022 at 9:58 AM BST, Ludovic Courtès wrote:

Toggle quote (3 lines)

> Is there a bug report, and do we have system tests for this

> functionality?

I don't believe there are system tests for greetd, no. There is

a bug report, though: https://issues.guix.gnu.org/56971.

Toggle quote (2 lines)

> I admit I know little about greetd and cases where it might be used.

As I understand it, greetd is a daemon that handles the sensitive parts

of display managers, which it calls 'greeters'. It allows you to write a

by simply writing a GUI that sends JSON messages to the socket when it

gets input.

So the problem is some greeters try to talk to seatd, but since they

don't have the right permissions, they bail out.

-- (

muradm wrote on 8 Aug 2022 20:50

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)

Message-ID:87mtcezhty.fsf@muradm.net

Attachment: v3-0001-gnu-seatd-service-type-Should-use-seat-group.patch

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

Toggle quote (10 lines)> 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

Toggle quote (4 lines)

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

Toggle quote (8 lines)>> * 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

Toggle quote (9 lines)>> +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".

Toggle quote (7 lines)>> +  (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

Toggle quote (1 lines)

> Cheers

muradm wrote on 8 Aug 2022 20:55

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87iln2zhh2.fsf@muradm.net

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (23 lines)> Hi,
>
> "(" <paren@disroot.org> skribis:
>
>> On Sat Aug 6, 2022 at 9:46 PM BST, Ludovic Courtès wrote:
>>> I guess I’m missing some context: is this fixing a bug 
>>> currently
>>> present?  (Apologies if this has been discussed elsewhere!)
>>
>> This is one of two patches that fix a problem where any greetd 
>> greeter
>> more complex than agreety hangs on boot, basically rendering 
>> greetd
>> useless. I think the underlying cause is their being unable to 
>> connect
>> to seatd.sock?
>>
>> At least, that's the symptom I know about. I'm not sure whether 
>> there
>> are others.
>
> Is there a bug report, and do we have system tests for this
> functionality?

Problem started with conversation on guix-devel, and related

commit.

Last message of thread:

https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00021.html

I was travelling and missed that change, when I

"guix pull && guix system reconfigure"ed at home and realized the

problem, I submitted fixes in the form of two patches 56690 and

56699.

Then I was asked to open a bug report in guix-devel list, which

is:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56971

Toggle quote (5 lines)>
> I admit I know little about greetd and cases where it might be 
> used.
> Having system tests for that would help make sure the relevant
> functionality works.

There is:

make check-system TESTS="minimal-desktop"

Patches in 56690 and 56699 now include the tests for this case as

well.

Toggle quote (3 lines)

> Thanks,

> Ludo’.

muradm wrote on 8 Aug 2022 21:44

Recipients:(name . ()(address . paren@disroot.org)

Message-ID:87a68ezfa4.fsf@muradm.net

"(" <paren@disroot.org> writes:

Toggle quote (19 lines)> On Mon Aug 8, 2022 at 9:58 AM BST, Ludovic Courtès wrote:
>> Is there a bug report, and do we have system tests for this
>> functionality?
>
> I don't believe there are system tests for greetd, no. There is
> a bug report, though: <https://issues.guix.gnu.org/56971>.
>
>> I admit I know little about greetd and cases where it might be 
>> used.
>
> As I understand it, greetd is a daemon that handles the 
> sensitive parts
> of display managers, which it calls 'greeters'. It allows you to 
> write a
> login program without having to write those difficult and 
> sensitive parts
> by simply writing a GUI that sends JSON messages to the socket 
> when it
> gets input.

For greetd/greeter this is fine explanation.

Toggle quote (3 lines)

> So the problem is some greeters try to talk to seatd, but since

> they

> don't have the right permissions, they bail out.

To be more correct here, greeter that requires both talking to 
greetd
and talking to seatd via libseat. Suppose gtkgreet which is 
running
with sway. So greetd will start greeter which is
"sway -c config-which-starts-gtkgreet.conf". Now you have two 
processes
in the scope of greeter, one is sway which has to talk to swatd 
via
libseat and the other is gtkgreet which is going to talk with 
greetd.

The one who bails out is sway here due to lack of permissions for
seatd.sock for talking to seatd via libseat.

Toggle quote (2 lines)

> -- (

Liliana Marie Prikler wrote on 9 Aug 2022 08:57

Recipients:(name . muradm)(address . mail@muradm.net)

Message-ID:063eee23b1ff1b0f288d5e465aa5bac1862c9bb8.camel@ist.tugraz.at

Am Montag, dem 08.08.2022 um 21:50 +0300 schrieb muradm:

Toggle quote (7 lines)> > 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?

Toggle quote (6 lines)> > > +� (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

muradm wrote on 9 Aug 2022 21:47

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)

Message-ID:87y1vxxjrt.fsf@muradm.net

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

Toggle quote (18 lines)> 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.

Toggle quote (21 lines)>> > > +� (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.

Toggle quote (1 lines)

> Cheers

Liliana Marie Prikler wrote on 10 Aug 2022 10:07

Recipients:(name . muradm)(address . mail@muradm.net)

Message-ID:feefa8add73babb6fb99636e1e676b1eae309c89.camel@ist.tugraz.at

Am Dienstag, dem 09.08.2022 um 22:47 +0300 schrieb muradm:

Toggle quote (27 lines)> 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*?

Toggle quote (26 lines)> > > > > +� (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

muradm wrote on 13 Aug 2022 19:39

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)

Message-ID:87mtc8112x.fsf@muradm.net

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

Toggle quote (42 lines)> 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.

Toggle quote (4 lines)

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

Toggle quote (1 lines)

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

Toggle quote (1 lines)

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

Toggle quote (41 lines)>> > > > > +� (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.

Toggle quote (1 lines)

> Cheers

muradm wrote on 22 Aug 2022 22:17

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)

Message-ID:8735doyqs4.fsf@muradm.net

Now accepts either string or user-group as group.

Attachment: v4-0001-gnu-seatd-service-type-Should-use-seat-group.patch

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

Toggle quote (94 lines)> 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 wrote on 26 Aug 2022 19:06

Re: greeter user permissions are not enough to talk with seatd

Recipients:(name . muradm)(address . mail@muradm.net)

Message-ID:400cf1fed0d340398da6e2e0e32bebdb8fd842ef.camel@gmail.com

Am Donnerstag, dem 04.08.2022 um 12:45 +0300 schrieb muradm:

Toggle quote (5 lines)> * 56690 - gnu: seatd-service-type: Should use seat group.
> With this change, if seatd-service-type is present in the
> system configuration, "seat" group will be added, and seatd
> will run as root/seat. Group is configurable, but default is 
> "seat".

I made it so that by default the sanitizer is used to turn the string

"seat" into a group and used (ice-9 match), reducing some needless

redundancy. I also reworded the manual to the best of my ability

following our conversations and adapted the commit message.

Toggle quote (5 lines)> * 56699 - gnu: greetd-service-type: Add greeter-extra-groups 
> � config field.
> With this change, if user wants to use seatd-service-type with
> greeter requiring seatd.sock, he can add "seat" group to
> greeter-extra-groups field.

I fixed some minor issue in the manual and reindented the marionette-

type in the tests, also reworded the commit message.

I didn't get the chance to run the system tests – some timeout causes

the marionette build to fail on my machine – but I verified

independently that at least the seatd socket has the right permissions.

I hope this will be enough for you to get gtkgreet running.

Cheers

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 56690@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 56690

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date