todo.sr.ht

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.

#43 greetd + tuigreet permission denied 2 months ago

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.

#43 greetd + tuigreet permission denied 2 months ago

on ~kennylevinsen/greetd

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

#43 greetd + tuigreet permission denied 2 months ago

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.

#42 Fixed dependency on VT 1 2 months ago

on ~kennylevinsen/greetd

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

#42 Fixed dependency on VT 1 2 months ago

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.

#41 Failed Howdy authentication crashes greetd 2 months ago

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.

#19 How to use embedded seatd(builtin) in libseat ? 2 months ago

Comment by ~kennylevinsen on ~kennylevinsen/seatd

REPORTED RESOLVED CLOSED

#19 How to use embedded seatd(builtin) in libseat ? 2 months ago

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