~kennylevinsen/greetd#43: 
greetd + tuigreet permission denied

I don't actually know the whole story here, but I have been trying various things for almost 5 hours over the past week to get this working...

I have installed greetd, enabled it in systemd and set a graphical target. On boot greetd is started and the default session is run.

tuigreet is installed as follows

    log "Installing tuigreet Greeter"
    git clone https://github.com/apognu/tuigreet .src/tuigreet
    (\
        cd .src/tuigreet \
        && cargo build --release \
        && sudo mv target/release/tuigreet /usr/local/bin/tuigreet
    )
    onfailure $? "failed to install tuigreet"

and greetd is installed via dnf

sudo dnf install greetd

I made sure to make the /etc/greetd/ directory and its contents readable by all via the following command as recommended in the FAQ.

sudo chmod -R go+r /etc/greetd/

then I start the daemon via the command (or on system boot)

systemctl enable --now greetd

but the permission denied error when executing /usr/local/bin/tuigreet persists. In fact the system tries to access tuigreet multiple times and then just freezes...

here are the current settings for these directories...

[rusty@fedora ~]$ ll /etc/greetd
.rw-r--r--@ 539 root 21 Mar 15:31 config.toml
[rusty@fedora ~]$ ll /usr/local/bin/tuigreet
.rwxr-xr-x@ 5.7M root 21 Mar 14:22 /usr/local/bin/tuigreet

I am not sure what else I need to try but I feel like I have tried to do just about everything... By the way one thing I noticed is that this application will work if the socket file is owned by the user which executes tuigreet... If you could point me in the right direction here I would be grateful.

Status
RESOLVED CLOSED
Submitter
Scott Mattan
Assigned to
No-one
Submitted
10 months ago
Updated
10 months ago
Labels
No labels applied.

Scott Mattan 10 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 10 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 10 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 10 months ago

~kennylevinsen 10 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 10 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 10 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 10 months ago

Register here or Log in to comment, or comment via email.