GNU bug report logs - #65769
greetd-wlgreet-sway-session result is blinking cursor

Previous Next

Full log

View this message in rfc822 format

From: "David Arroyo" <david <at> aqwari.net>
To: "Josselin Poiret" <dev <at> jpoiret.xyz>, chris <chris <at> bumblehead.com>, "(" <paren <at> disroot.org>
Cc: 65769 <at> debbugs.gnu.org
Subject: bug#65769: greetd-wlgreet-sway-session result is blinking cursor
Date: Thu, 31 Oct 2024 21:56:19 +0100

On Sat, Sep 9, 2023, at 11:11, Josselin Poiret via Bug reports for GNU Guix wrote:
> I'd still like feedback from actual users of wlgreet, as I have not used
> it myself.  I do believe the only way it could work is because something
> takes care of creating the runtime directory.

This is my conclusion as well. I ran into this issue today when trying to
setup a minimal install with sway. I had to switch from seatd to elogind.
Here's my working config:

https://paste.sr.ht/~droyo/6cd5f6c1cb12220d10dbcbe0f92f317dfdc88aee

Here's my understanding of the issue;

* greetd runs as root, but when the user switches to a vt, it forks a
  child process to run the default_session command (agreety, wlgreet,
  etc).  This process runs as the `(default-session-user config)`
  (default "greeter".

* sway requires XDG_RUNTIME_DIR to exist, but there is nothing creating
   XDG_RUNTIME_DIR on behalf of "greeter", so it repeatedly crashes
   until herd disables the `term-ttyX` service corresponding to the
   wlgreet terminal.

* When using elogind, this is taken care of for "greeter" by the
   pam_elogind pam module, which is added to all pam configs, including
   greetd's, by the `elogin-service-type` service. On other distros,
   pam_systemd performs the same task.

This issue is summarized by the author of seatd here:

https://git.sr.ht/~kennylevinsen/seatd-docs/tree/master/item/index.md#xdg_runtime_dir-not-set

The solution prescribed is to create the rundir from a script on startup
or with a pam module. I was curious why the existing `pam_mount(5)`
module in greetd's existing PAM configuration did not handle creation
for the "greeter" user as well. The pam_mount configuration linked to
/etc/security/greetd_pam_mount.conf.xml does not discriminate against
this user.

I set `debug=1` in /etc/security/greetd_pam_mount.conf.xml and restarted
the system. Here's the `pam_mount` logs for the "greeter" user's session:

	greetd: (pam_mount.c:568): pam_mount 2.18: entering session stage
	greetd: (pam_mount.c:629): no volumes to mount
	greetd: command: '/gnu/store/18wjrghh95hy8l4nmr22lpsjgjpdqbax-greetd-pam-mount-2.18/sbin/pmvarrun' '-u' 'greeter' '-o' '1'
	greetd: (pam_mount.c:441): pmvarrun says login count is 2
	greetd: (pam_mount.c:660): done opening session (ret=0)
	greetd: (pam_mount.c:706): received order to close things
	greetd: (pam_mount.c:709): No volumes to umount

And for my session (after logging into a separate vt running agreety):

	greetd: (pam_mount.c:568): pam_mount 2.18: entering session stage
	greetd: (mount.c:781): Could not get realpath of /run/user/1000: No such file or directory
	greetd: (mount.c:251): Mount info: globalconf, user=droyo <volume fstype="tmpfs" server="(null)" path="none" mountpoint="/run/user/1000" cipher="(null)" fskeypath="(null)" fskeycipher="(null)" fskeyhash="(null)" options="noexec,nosuid,nodev,size=1g,mode=0700,uid=1000,gid=998" /> fstab=0 ssh=0
	greetd: (mount.c:305): mkmountpoint: checking /run
	greetd: (mount.c:305): mkmountpoint: checking /run/user
	greetd: (mount.c:345): mkdir[0] /run/user
	greetd: (mount.c:351): chown /run/user -> 1000:998
	greetd: (mount.c:305): mkmountpoint: checking /run/user/1000
	greetd: (mount.c:329): mkdir[1000] /run/user/1000
	greetd: (mount.c:660): Password will be sent to helper as-is.
	greetd: command: '/gnu/store/w62dxljn51hcrszyxjb1dffhbvrl8iqm-util-linux-2.37.4/bin/mount' '-onoexec,nosuid,nodev,size=1g,mode=0700,uid=1000,gid=998' '-ttmpfs' 'none' '/run/user/1000'

I could not find any obvious problem reading pam_mount.c, so I read the
pam_mount.conf file a little closer and found the issue:

	<volume sgrp="users" fstype="tmpfs" ...

Per pam_mount.conf(5), sgrp restricts pam_mount's activity to users in
the "users" group. So adding "users" to `greeter-supplementary-groups`
resolves the issue.

Sorry for being long-winded. I thought maybe including the steps I took
would help others stuck in similar issues troubleshoot. As far as fixing
this one, should we update the example in

https://guix.gnu.org/manual/en/html_node/Base-Services.html#index-greetd_002dwlgreet_002dsway_002dsession

or is it better to force a fix and modify pam_mount or make the
greetd-wlgreet-* sessions enforce some check on group membership?

Another thing, the /run/user created by pam_mount is owned by the
first session's user (greeter:greeter), while with pam_elogind it's owned
by root:root. It doesn't seem to cause a problem, but I just thought I'd
call that out.

David

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.