Scott Mattan 1 year, 6 months ago · edit

I forgot to add, my config file looks like this

# The VT to run the greeter on. Can be "next", "current" or a number
# designating the VT.
vt = 1

# The default session, also known as the greeter.
[default_session]

# `agreety` is the bundled agetty/login-lookalike. You can replace `/bin/sh`
# with whatever you want started, such as `sway`.
command = "tuigreet --cmd Hyperland"

# The user to run the command as. The privileges this user must have depends
# on the greeter. A graphical greeter may for example require the user to be
# in the `video` group.
user = "greetd"

and my user was configured by the dnf package like this

greetd:x:989:988:greetd daemon:/var/lib/greetd:/usr/sbin/nologin

also, this is the unit file if this is necessary.

[Unit]
Description=Greeter daemon
After=systemd-user-sessions.service plymouth-quit-wait.service
After=getty@tty1.service
Conflicts=getty@tty1.service

[Service]
Type=simple
ExecStart=greetd
IgnoreSIGPIPE=no
SendSIGHUP=yes
TimeoutStopSec=30s
KeyringMode=shared
Restart=always
RestartSec=1
StartLimitBurst=5
StartLimitInterval=30

[Install]
Alias=display-manager.service

~kennylevinsen 1 year, 6 months ago

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.

Scott Mattan 1 year, 6 months ago · edit

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

Scott Mattan referenced this from #43 1 year, 6 months ago

~kennylevinsen 1 year, 6 months ago

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.

~alebastr 1 year, 6 months ago

Can you show the output of ls -Z /usr/local/bin/tuigreet?

I suspect that it's labeled as user_home_t and the transition from xdm_t is blocked. If that's the case, restorecon -Fv /usr/local/bin/tuigreet should fix the problem.

Scott Mattan 1 year, 6 months ago · edit

I was doing investigation on things based on kennylevinsen's comment by switching the greet command to /bin/bash and this allowed me to check various settings.. one thing I noticed is exactly as you mentioned which was the user context shown by id -Z was a system user context, whereas the tuigreet context was an unconfined user context.

I didn't know how to change it though... and like magic the notification for alebastr's comment appeared on my screen! Perfect timing, and yes, this was the solution. I've added it to my install script!! its working now!! thanks for the help guys!! I really appriciate it!!

~kennylevinsen REPORTED CLOSED 1 year, 6 months ago