Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Fedora Workstation is configured to allow reboot and poweroff for non-root users (both in %wheel and outside of it). In F44, it works both in gnome-terminal and VT console. In F45, it works in gnome-terminal, no longer in VT console. I see this error instead: > $ reboot > Call to Reboot failed: Access denied as the requested operation requires interactive authentication. However, interactive authentication has not been enabled by the calling program. I suspect the reason of this regression is the switch to kmscon. Version-Release number of selected component (if applicable): kmscon-10.0.3-2.fc45.x86_64 How reproducible: always Steps to Reproduce: 1. Install F45 Workstation 2. Create a user 3. Switch to VT and run "reboot" or "poweroff" 4. Compare to gnome-terminal behavior, or VT behavior in F44
Proposing for a blocker discussion: https://fedoraproject.org/wiki/Fedora_45_Beta_Release_Criteria#Shutdown,_reboot,_login,_logout
It looks like systemd doesn't recognize kmscon as a local console, so it treats it as an ssh session. You can still reboot/poweroff using `systemctl reboot` or `systemctl poweroff`, but they ask for your password.
AGREED RejectedFinalBlocker AcceptedFinalFreezeException Discussed at the 2026-09-14 (blocker / freeze exception) review meeting: This was rejected on the basis it's just too narrow a conditional violation (only non-privileged execution of bare commands in a VT fails, all other possibilities work). It's accepted for a Freeze Exception as it is a somewhat annoying and visible issue and it'd be nice to have it fixed at release if possible. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-09-14/f45-blocker-review.2026-09-14-16.01.log.txt
Common issue documentation: https://discussion.fedoraproject.org/t/common-issue/202025
reboot calls: org.freedesktop.login1.Manager.RebootWithFlags /usr/share/polkit-1/actions/org.freedesktop.login1.policy has <action id="org.freedesktop.login1.power-off"> <description gettext-domain="systemd">Power off the system</description> <message gettext-domain="systemd">Authentication is required to power off the system.</message> <defaults> <allow_any>auth_admin_keep</allow_any> <allow_inactive>auth_admin_keep</allow_inactive> <allow_active>yes</allow_active> </defaults> <annotate key="org.freedesktop.policykit.imply">org.freedesktop.login1.set-wall-message</annotate> </action> So IIUC, the decision whether to allow the operation is done by polkit. OTOH, polkit also calls back to systemd to determine the state of the session, so maybe the problem in the end might be in systemd, but let's reassign to polkit for comments for now.
$ loginctl session-status 1 1 - fedora (1000) Since: Tue 2026-09-15 08:47:57 CEST; 1h 58min ago State: active Leader: 804 (login) TTY: pts/0 Remote: no Service: login Type: tty Class: user Idle: no Unit: session-1.scope ├─804 "login -- fedora" └─828 -bash Sep 15 08:47:57 rawhide systemd[1]: Started session-1.scope - Session 1 of User fedora. Sep 15 08:47:57 rawhide login[804]: pam_unix(login:session): session opened for user fedora(uid=1000) by fedora(uid=0) Sep 15 08:47:57 rawhide login[804]: LOGIN ON pts/0 BY fedora This looks OK. polkit_backend_session_monitor_is_session_active checks for state == active, so this should be OK. Don't know why the request is rejected.
** (polkitd:1413): DEBUG: 10:52:45.507: system-bus-name::1.3 is inquiring whether system-bus-name::1.36 is authorized for org.freedesktop.login1.power-off ** (polkitd:1413): DEBUG: 10:52:45.512: user of caller is unix-user:root ** (polkitd:1413): DEBUG: 10:52:45.512: user of subject is unix-user:fedora ** (polkitd:1413): DEBUG: 10:52:45.512: checking whether system-bus-name::1.36 is authorized for org.freedesktop.login1.power-off ** (polkitd:1413): DEBUG: 10:52:45.518: 0x562b6bdd1ad0 ** (polkitd:1413): DEBUG: 10:52:45.518: Checking whether session 1 is active. ** (polkitd:1413): DEBUG: 10:52:45.518: Session 1 has UID 1000. ** (polkitd:1413): DEBUG: 10:52:45.518: UID 1000 has state active. ** (polkitd:1413): DEBUG: 10:52:45.518: subject is in session 1 (local=0 active=1) ** (polkitd:1413): DEBUG: 10:52:45.521: checking whether system-bus-name::1.36 is authorized for org.freedesktop.login1.power-off-ignore-inhibit ** (polkitd:1413): DEBUG: 10:52:45.522: 0x562b6bdb7f50 ** (polkitd:1413): DEBUG: 10:52:45.522: Checking whether session 1 is active. ** (polkitd:1413): DEBUG: 10:52:45.522: Session 1 has UID 1000. ** (polkitd:1413): DEBUG: 10:52:45.522: UID 1000 has state active. ** (polkitd:1413): DEBUG: 10:52:45.522: subject is in session 1 (local=0 active=1) ** (polkitd:1413): DEBUG: 10:52:45.524: challenge (implicit_authorization = auth_admin_keep) ** (polkitd:1413): DEBUG: 10:52:45.524: ** (polkitd:1413): DEBUG: 10:52:45.524: checking whether system-bus-name::1.36 is authorized for org.freedesktop.login1.power-off-multiple-sessions ** (polkitd:1413): DEBUG: 10:52:45.525: 0x562b6bd7f810 ** (polkitd:1413): DEBUG: 10:52:45.525: Checking whether session 1 is active. ** (polkitd:1413): DEBUG: 10:52:45.525: Session 1 has UID 1000. ** (polkitd:1413): DEBUG: 10:52:45.525: UID 1000 has state active. ** (polkitd:1413): DEBUG: 10:52:45.525: subject is in session 1 (local=0 active=1) ** (polkitd:1413): DEBUG: 10:52:45.526: challenge (implicit_authorization = auth_admin_keep) ** (polkitd:1413): DEBUG: 10:52:45.526: challenge (implicit_authorization = auth_admin_keep) Right, so polkit says the session is local=0. So maybe this is caused by logind not listing a seat for session 1.
Oh, so this is somehow magically caused by selinux. After setenforce 0, the seat is set, after I do setenforce 1 again, it is unset: Sep 15 13:07:40 rawhide login[1468]: pam_systemd(login:session): pam-systemd: initializing (class_pam= type_pam= desktop_pam= area_pam= inhibit_what=)... Sep 15 13:07:40 rawhide login[1468]: pam_systemd(login:session): Initial state: service=login display= tty=/dev/pts/0 remote_user= remote_host= seat=seat0 vtnr=1 type= class= desktop= area= incomplete=no inhibit_what= Sep 15 13:07:40 rawhide login[1468]: pam_systemd(login:session): Automatically chose session type 'tty'. Sep 15 13:07:40 rawhide login[1468]: pam_systemd(login:session): Automatically chose session class 'user'. Sep 15 13:07:40 rawhide login[1468]: pam_systemd(login:session): Asking logind to create session: uid=1000 pid=1468 service=login type=tty class=user desktop= seat=seat0 vtnr=1 tty=pts/0 display= remote=no remote_user= remote_host= Sep 15 13:08:14 rawhide login[1577]: pam_systemd(login:session): pam-systemd: initializing (class_pam= type_pam= desktop_pam= area_pam= inhibit_what=)... Sep 15 13:08:14 rawhide login[1577]: pam_systemd(login:session): Initial state: service=login display= tty=/dev/pts/0 remote_user= remote_host= seat= vtnr=0 type= class= desktop= area= incomplete=no inhibit_what= Sep 15 13:08:14 rawhide login[1577]: pam_systemd(login:session): Automatically chose session type 'tty'. Sep 15 13:08:14 rawhide login[1577]: pam_systemd(login:session): Automatically chose session class 'user'. Sep 15 13:08:14 rawhide login[1577]: pam_systemd(login:session): Asking logind to create session: uid=1000 pid=1577 service=login type=tty class=user desktop= seat= vtnr=0 tty=pts/0 display= remote=no remote_user= remote_host=
OK, so I remember vaguely that selinux did something strange with secure_getenv(). pam_systemd uses secure_getenv("XDG_SEAT") and secure_getenv("XDG_VTNR") and those return NULL when selinux is enforcing. If I patch pam_systemd to use normal getenv(), things work again. So kmscon sets the variable properly and they are present, but SELinux prevents pam_systemd from reading them.
Thanks a lot for the debugging session !
I discussed this with Lennart, and he think that we should modify kmscon to set the pam variables in addition to setting the environment variables. Then the secure_getenv stuff will not matter, and things should work again.
OK, this plan did not quite work, since kmscon doesn't deal with the PAM stack directly. I think we should modify the selinux policy after all. See https://github.com/fedora-selinux/selinux-policy/pull/3426, please review.
FEDORA-2026-57cfe97999 (selinux-policy-45.19-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-57cfe97999
FEDORA-2026-57cfe97999 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-57cfe97999` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-57cfe97999 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #13) > FEDORA-2026-57cfe97999 (selinux-policy-45.19-1.fc45) has been submitted as > an update to Fedora 45. > https://bodhi.fedoraproject.org/updates/FEDORA-2026-57cfe97999 Fixes the problem, thanks.
FEDORA-2026-57cfe97999 (selinux-policy-45.19-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.