I have a strange issue, trying to run mate-screensaver-dialog with root privileges using SUID bit:
[root@localhost ~]# ls -l /usr/libexec/mate-screensaver-dialog
-rwsr-s--t. 1 root root 72920 мар 22 2021 /usr/libexec/mate-screensaver-dialog
And with that, launching this (from a user user) and looking for the effective uid gives me info of the user, who ran this executable:
[root@localhost ~]# ps aux | grep screensaver-dialog
user 3673 0.6 0.4 894304 38504 pts/3 Sl+ 19:29 0:00 /usr/libexec/mate-screensaver-dialog
This case happens, when user session is locked by a timeout with a screensaver. So can anyone please help me, why could SUID bit do not work for this case? I would be glad for any advice.
Using OS: RedOS 7.3, x64
Browsing through the source code on github i have found this comment:
Initializations that potentially take place as a priveleged user: If the executable is setuid root, then these initializations are run as root, before discarding privileges.
The function which this comment addresses:
static gboolean privileged_initialization(int* argc, char** argv)
Is called from the main function here.
In addition to that, the privileged_initialization function calls another function hack_uid present in the setuid.h header in the same directory which has a similar comment above it:
If we've been run as setuid or setgid to someone else (most likely root) turn off the extra permissions so that random user-specified programs don't get special privileges.
Based on this i assume that the executable follows a common practice of dropping elevated privileges before running actual functionality. This is a popular approach of reducing impact of potential security holes.
Effectively, it means that the executable probably starts running as root, because of the SUID bit, performs any tasks that actually need root privileges and afterwards reduces the privileges to the user level.