`pam_unix(system-auth:account): setuid failed: Operation not permitted` and other `xsecurelock` messages in `journalctl` after resuming from suspend

[xfzv]

I'm using the following systemd service unit to lock my session before suspending/hibernating:

# /etc/systemd/system/lock-screen-suspend-hibernate@.service

[Unit]
Description=Lock screen before suspend/hibernate
Before=suspend.target
Before=suspend-then-hibernate.target
Before=hibernate.target
Before=hybrid-sleep.target
Before=sleep.target

[Service]
User=%I
Type=simple
Environment=DISPLAY=:0
Environment=XSECURELOCK_AUTH_CURSOR_BLINK=0
Environment=XSECURELOCK_COMPOSITE_OBSCURER=0
Environment=XSECURELOCK_DATETIME_FORMAT="%%Y-%%m-%%d - %%H:%%M"
Environment=XSECURELOCK_DISCARD_FIRST_KEYPRESS=0
Environment=XSECURELOCK_PASSWORD_PROMPT=time_hex
Environment=XSECURELOCK_SHOW_DATETIME=1
Environment=XSECURELOCK_SHOW_HOSTNAME=0
Environment=XSECURELOCK_SHOW_KEYBOARD_LAYOUT=0
Environment=XSECURELOCK_SHOW_USERNAME=0

ExecStart=/usr/bin/xsecurelock
ExecStartPost=/usr/bin/sleep 1
TimeoutSec=infinity

[Install]
WantedBy=suspend.target
WantedBy=suspend-then-hibernate.target
WantedBy=hibernate.target
WantedBy=hybrid-sleep.target
WantedBy=sleep.target

I have no issue whatsoever for now, it works as expected. After resuming from suspend, I can unlock my session with my user password just fine.

However, journalctl -u lock-screen-suspend-hibernate@.service always contains the following (in this case after suspending):

% journalctl -u lock-screen-suspend-hibernate@.service
systemd[1]: Starting Lock screen before suspend/hibernate...
systemd[1]: Started Lock screen before suspend/hibernate.
xsecurelock[52239]: YYYY-MM-DDTHH:MM:SSZ 52239 xsecurelock: Someone overlapped the composite overlay window window. Undoing that.
xsecurelock[52239]: YYYY-MM-DDTHH:MM:SSZ 52239 xsecurelock: Someone overlapped the background window. Undoing that.
xsecurelock[52239]: YYYY-MM-DDTHH:MM:SSZ 52239 xsecurelock: MaybeRaiseWindow miss: something obscured my window 27262985 but I can't find it.
authproto_pam[52559]: pam_unix(system-auth:account): setuid failed: Operation not permitted
systemd[1]: lock-screen-suspend-hibernate@xfzv.service: Deactivated successfully.

Just curious as to what could trigger these messages. Tried without Environment=XSECURELOCK_COMPOSITE_OBSCURER=0 (Picom user, I'm using it to avoid the "INCOMPATIBLE COMPOSITOR, PLEASE FIX!" text as suggested in Known Compatibility Issues but it doesn't make any difference.

Should I just ignore these considering everything works fine?

Thanks!

[dimich-dmb]

@xfzv I encountered the same "setuid failed: Operation not permitted" message but from xscreensaver. It doesn't look like related to xsecurelock but rather to linux-pam.

[rdslw]

This is not pam problem per se, but rather configuration of your local system.

You have few solutions:

1. ask xsecurelock to use different (dedicated) pam service name i.e. "xsecurelock" and configure it there
2. simply chmod u+s /usr/lib/xsecurelock/authproto_pam
3. leave authproto_pam without setuid, but add 'quiet' to:
   3.a. /etc/pam.d/system-auth account pam_unix line (will apply to everything)
   3.b. to custom /etc/pam.d/xsecurelock (but in such case you might also remove it)

Full explanation is here: https://chatgpt.com/share/68f8e08c-bd04-8011-915c-2b7567fc9e6a

[dimich-dmb]

This is not pam problem per se, but rather configuration of your local system.

In Arch xscreensaver binary has suid bit set but "setuid failed: Operation not permitted" is logged as well. However, severity of the log record is "debug".

[rdslw]

This is not pam problem per se, but rather configuration of your local system.

In Arch xscreensaver binary has suid bit set but "setuid failed: Operation not permitted" is logged as well. However, severity of the log record is "debug".

@dimich-dmb can you quote full line from logs? I would like to see which pam module is emitting this message.

if possible also content of /etc/pam.d/FILENAMEOFPAMMODULE would help.

[dimich-dmb]

@dimich-dmb can you quote full line from logs? I would like to see which pam module is emitting this message.

Oct 23 17:22:59 dimich xscreensaver-auth[34952]: pam_unix(xscreensaver:account): setuid failed: Operation not permitted

Appears after entering password to unlock.

if possible also content of /etc/pam.d/FILENAMEOFPAMMODULE would help.

/etc/pam.d/xscreensaver:

#%PAM-1.0

# Fedora Core 5:
auth       include      system-auth

# SuSE 9.0: (along with "configure --with-passwd-helper" and "unix2_chkpwd")
# auth     required       pam_unix2.so  nullok

# Distant past:
# auth       required   /lib/security/pam_pwdb.so shadow nullok

# Account validation
account include system-auth

/etc/pam.d/system-auth:

/etc/pam.d/system-auth 
#%PAM-1.0

auth       required                    pam_faillock.so      preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
#-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

#-account   [success=1 default=ignore]  pam_systemd_home.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

#-password  [success=1 default=ignore]  pam_systemd_home.so
password   required                    pam_unix.so          try_first_pass nullok shadow
password   optional                    pam_permit.so

#-session   optional                    pam_systemd_home.so
session    required                    pam_limits.so
session    required                    pam_unix.so
session    optional                    pam_permit.so

$ stat -c "%a %A %U %G" /usr/lib/xscreensaver/xscreensaver-auth 
4755 -rwsr-xr-x root root

[dimich-dmb]

In Arch xscreensaver binary has suid bit set but "setuid failed: Operation not permitted" is logged as well. However, severity of the log record is "debug".

Hm, seems I began to understand what's the problem. I was wrong about xscreensaver binary: it has no suid bit. xscreensaver-auth has, but PAM configured for xscreensaver.

[rdslw]

@dimich-dmb you have a few options to solve it:

1. edit /etc/pam.d/xscreensaver and replace line "account include system-auth" with three lines, first being commented out:

#disabled# account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

You will not have error logs, but you will also loose checks (on xscreensaver unlock) if password is too old or account is expired/locked. If this is your own account, on (a guess) single user machine, where you have no reason to lock your account, go for it.

2. add 'quiet' to pam_unix.so to supress logging (only on account section)

3. try to find solution on xscreensaver -> this bug/problem of yours is not related to xsecurelock (the repo we're currently discussing it :) so you should report it there, not here. I suspect that this is not a simple chmod u+s solution, as I dont know architecture of xscreensaver, how it retains root creds etc.

[dimich-dmb]

@dimich-dmb you have a few options to solve it

@rdslw Thank you for detailed answer. However, I'm not looking for workaround to this "issue". I just wanted to point out that if two different applications using the same library produce the same error message from this library, likely the root cause should be sought in the library. Although, it's not always the case. Especially considering that we don't know severity of "setuid failed: Operation not permitted" from original issue description, since PAM produces the same message with different severities in slightly different cases.