swaylock
swaylock copied to clipboard
swaywm
setuid: Unable to drop root (we shouldn't be able to restore it after setuid): Success
OS: Linux Gentoo
I have setuid on my swaylock binary:
~ ls -la /usr/bin/swaylock
-rws--s--x 1 root root 87504 Jun 25 12:14 /usr/bin/swaylock*
However, when attempting to use it, it cannot drop root:
~ swaylock
2022-07-01 21:14:11 - [swaylock-1.6/shadow.c:36] Unable to drop root (we shouldn't be able to restore it after setuid): Success
This usually indicates that swaylock is run as actual root, rather than being run as a user and having SUID upgrade privileges.
It should be notes that the preferred use is through PAM, not through SUID and the built-in shadow handling.
Strange, because the user is not root, but my user account
~ whoami
rok
~ swaylock
2022-07-02 13:35:50 - [swaylock-1.6/shadow.c:36] Unable to drop root (we shouldn't be able to restore it after setuid): Success
It should be notes that the preferred use is through PAM, not through SUID and the built-in shadow handling.
Right, but these times it is better to have a lean system, as less code means less potential security vulnerabilities. PAM seems bloated, compared to lean approach of sway.
Right, but these times it is better to have a lean system, as less code means less potential security vulnerabilities. PAM seems bloated, compared to lean approach of sway.
PAM is under far more scrutiny than our swaylock SUID helper, so from a security standpoint it is the better solution.
Whether something is "bloated" is subjective.
Strange, because the user is not root, but my user account
Hmm, I will have to take a look.
Seems like the reason could be file capabilities set (CAP_SYS_ADMIN) by Gentoo if USE="-pam filecaps"..
See also Gentoo Bug 921584 where I propose fixing the applied capability as well as a basic patch to make swaylock work with file capabilities (but that way would not solve issue #175 ). A more complete patch may also rather use libcap than performing syscalls directly in order to be less Linux-only.
