Denmark
This space intentionally left blank.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
REPORTED
RESOLVED CLOSEDComment by ~kennylevinsen on ~kennylevinsen/greetd
On 3/21/23 15:50, ~Amos Onn wrote:
You are right, this was the issue, thanks! I guess this might be worth noting in the FAQ (that changing the VT in the config file is not enough, it also needs to be updated in the the systemd unit)?
Added.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
Try to
sudo -u greetd /usr/local/bin/tuigreet
. Alternatively,sudo -u greetd /bin/sh
and run tuigreet from that shell.greetd exec's
/bin/sh
as the target user, which then exec's whatever you asked for, in order to handle shell syntax, variable expansion .profile files and more. The error you are seeing is/bin/sh
failing to execute /usr/local/bin/tuigreet in the final greetd step. The full inline shell script is[ -f /etc/profile ] && . /etc/profile; [ -f $HOME/.profile ] && . $HOME/.profile; exec {}
, where {} is replaced by your session command.So, you should be able to reproduce the issue by just running tuigreet directly as that user. If it still works using sudo, then things get more hairy - possibly being related to the PAM stack or SELinux.
I don't think this is due to the chdir to $HOME as that would come later in the process if I am not mistaken?
chdir happens immediately before exec.
Hey! thanks for getting back to me, I can't actually find anywhere the logs are actually being preserved.. I Searched journalctl, for greetd unit but it was empty.
Do you know where I could find that information?
If I were to type a copy the error that is shown, it would be:
/bin/sh: line 1: /usr/local/bin/tuigreet: Permission denied /bin/sh: line 1: exec: /usr/local/bin/tuigreet: cannot execute: Permission denied [FAILED] Failed to start greetd.service - Greeter daemon.
as for the permissions of tuigreet itself it should be accessible for execution by everyone based on what I have shared above.
hmm.. it seems to halt before we get into the tuigreet package... the pam configuration is as follows!
greetd-greeter
#%PAM-1.0 # Load environment from /etc/environment and ~/.pam_environment auth required pam_env.so # Always let the greeter start without authentication auth required pam_permit.so # No action required for account management account required pam_permit.so # Can't change password password required pam_deny.so # Setup session session required pam_unix.so session optional pam_systemd.so
greetd
#%PAM-1.0 auth substack system-auth -auth optional pam_gnome_keyring.so -auth optional pam_kwallet5.so -auth optional pam_kwallet.so auth include postlogin account required pam_sepermit.so account required pam_nologin.so account include system-auth password include system-auth session required pam_selinux.so close session required pam_loginuid.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session include system-auth -session optional pam_gnome_keyring.so auto_start -session optional pam_kwallet5.so auto_start -session optional pam_kwallet.so auto_start session include postlogin
I don't think this is due to the chdir to $HOME as that would come later in the process if I am not mistaken?
------- Original Message ------- On Monday, March 27th, 2023 at 16:26, ~kennylevinsen outgoing@sr.ht wrote:
You didn't share the error in question or a log. Permission denied could indicate that the "greetd" user isn't allowed to read and execute tuigreet, or that it does not have its executable bit set. It could also be something in the PAM stack, the chdir to $HOME, or tuigreet itself.
-- View on the web: https://todo.sr.ht/~kennylevinsen/greetd/43#event-231255
Comment by ~kennylevinsen on ~kennylevinsen/greetd
You didn't share the error in question or a log. Permission denied could indicate that the "greetd" user isn't allowed to read and execute tuigreet, or that it does not have its executable bit set. It could also be something in the PAM stack, the chdir to $HOME, or tuigreet itself.
You are right, this was the issue, thanks! I guess this might be worth noting in the FAQ (that changing the VT in the config file is not enough, it also needs to be updated in the the systemd unit)?
On Tue, 21 Mar 2023 at 11:56, ~kennylevinsen outgoing@sr.ht wrote:
Assuming systemd, did you update the systemd unit so it matches the VT used? This normally contains a conflict clause that ensures that agetty does not start there.
-- View on the web: https://todo.sr.ht/~kennylevinsen/greetd/42#event-230472
Comment by ~kennylevinsen on ~kennylevinsen/greetd
Assuming systemd, did you update the systemd unit so it matches the VT used? This normally contains a conflict clause that ensures that agetty does not start there.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
There appears to be two issues here:
- When a greetd worker crashes, the login flow freezes.
- The greetd worker crashed when you used pam_howdy.
The stack suggests that pam_howdy, written in C++, throws an exception and aborts the process it is running in. This is not something we can (or should) handle, and so only the first of the issues is a greetd bug.
Regarding the crash cause, pam_howdy seems to be starting threads and having one of the joins fail. Getting the exception message might be helpful. If it went to stderr, you should be able to find it in greetd's log output. The crash cause may be that it expected something from the login manager, but regardless of the cause, pam modules should never crash.
Also note that having a PAM module spawn threads can be dangerous. Login managers need to fork, call various setup functions (some of which are not async-signal-safe), and then exec the final executable, but a multi-threaded program can only safely call async-signal-safe functions between fork and exec. It becomes the module authors responsibility that it is safe to call non-async-signal-safe functions after fork once conversation functions have returned.
Comment by ~kennylevinsen on ~kennylevinsen/seatd
REPORTED
RESOLVED CLOSEDComment by ~kennylevinsen on ~kennylevinsen/seatd
Just run seatd as a daemon. If your distribution does not have a service manager of any sort that could start seatd, then you can use seatd-launch for convenience.
The builtin backend requires compositor support for SUID privilege drop, which compositors have removed or are removing as there is no benefit to the builtin backend over running seatd as a daemon.