On 16/01/2025 13.15, Svante Signell wrote:
> Sorry no /dev/input for Hurd.
>
> ...
>
> On Hurd none of these above are present and neither of evdev, wscons!

The purpose of seatd is to give access to such privileged devices. You 
will need to implement support in seatd for the input and output device 
types that Hurd uses, similar to how wscons support was added for NetBSD 
and OpenBSD. This would be the device types that Xorg needs to open for 
input and output.

I am not familiar with Hurd, so I cannot tell you what device types this

> Running simpletest it asks for a "file". What file is expected here as input?

In .builds/archlinux.yml you can see it called as part of the smoketest. 
It should be a file path to a privileged file that seatd is to open for 
you, e.g. /dev/input/event0.

> I will try to install Devuan's Xorg in GNU/Hurd. However, some things are still
> unclear for me.
>
> - What triggers seatd when running in background?

seatd is a server that opens privileged devices (evdev, drm/kms, hidraw, 
wscons) on behalf of libseat clients (i.e., display servers) that 
themselves do not (and should not) have direct file access. It also

On 15/01/2025 23.08, Svante Signell wrote:
> Thanks, another stupid question:
> /simpletest -l debug /usr/lib/xorg/Xorg.wrap
> 00:00:00.000  [libseat/libseat.c:73] Seat opened with backend 'seatd'
> libseat_open_seat(listener: 0x1039d58, userdata: 0x1039d50) = 0x200009c0
> /simpletest -l debug /usr/lib/xorg/Xorg.wrap
> 00:00:00.000  [libseat/libseat.c:73] Seat opened with backend 'seatd'
> libseat_open_seat(listener: 0x1039d58, userdata: 0x1039d50) = 0x200009c0
> waiting for activation...waiting for activation...
>
> ??

On 14/01/2025 14.52, Svante Signell wrote:
> However, I don't yet know how to properly test seatd. Using xorg for testing is
> not possible without recompiling the whole xorg suite. This is due to the
> existence of the package xserver-xorg-legacy, see:

There's small included test client (simple_test), but that just tries to 
open a device without doing anything with it so it's not super exciting.

Devuan has a patched Xorg with libseat support, so maybe that is of 
interest. I have poked them about upstreaming before, but I don't think 
they have tried yet. There's pretty good built-in support for libseat 
across Wayland servers (e.g., weston and sway), but not sure if those 
run on Hurd.

Applied the embedded patch, thanks!

Applied, thanks!

Looking at pam-fprintf-grosshack, that thing is unsafe and broken beyond 
repair, and will cause anything from corrupt greetd states (likely the 
issue you're seeing) to outright memory corruption. There is no way to 
safely use that in greetd, nor a way for greetd to guard against issues 
when using it.

A valid PAM module cannot retract or interrupt a question. Once you have 
been asked a question, the only way for the process to continue is by 
answering the question.

Maybe we should change logging so that the message content can never get 
included, but that's a separate thing - this PAM module will never work 
or be safe to use.

I answered the issue, but for completeness for those following the list: The main change is that libseat no longer activates the session when using the logind backend, so if an inactive VT/TTY is targeted, a chvt before or after starting the session is required in the start scripts to make the session visible.

This activation is removed to allow starting sessions in the background, something Weston used to allow before adopting libseat.

An example of a fix is available here: https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1566

Applied, thanks!

> I am experiencing an issue with greetd and tuigreet when integrating Fprintd into PAM that results in the ability to login without the correct password or fingerprint.
>
> I would like to assume that the likely issue is user configuration (my mistake), but I can't see it yet, and want to open this discussion in case it could be a problem.

In the config you shared on IRC, both pam_unix.so and pam_fprintd.so 
were set to `sufficient`, which means that PAM stops immediately on 
success, but ignore failure.

You probably want something like the following, which should jump across 
the fprintd module if unix succeeds but ignores failure and moves on to 
fprintd, which then interrupts everything on failure.

auth requisite pam_nologin.so auth [success=1 default=ignore] 
pam_unix.so try_first_pass nullok