I'm writing a program to allow unprivileged users to mount overlay filesystems using a setuid binary. I've implemented a few safeguards to improve the program's security, but I'd like a more definitive checklist of potential security risks such a program might expose. Here are the safeguards I've implemented so far: - The program dissociates its mount namespace before performing any mounts, ensuring that other processes remain unaffected by the new mount. The program then runs a user-provided command inside that namespace. - It verifies that every lowerdir is readable by the user. For sub-items within each lowerdir, I assume that POSIX ACLs will prevent unauthorized access. - It ensures that the upperdir is both readable and writable by the user. Again, I rely on ACLs to enforce access restrictions on sub-items. - It verifies that the workdir is writable. Since the workdir must be empty for OverlayFS to function, I consider the risk there to be minimal. - It ensures that the mountpoint is writable by the user. - The program resets the effective UID and GID to the real user’s IDs immediately after completing the mount operations. These measures cover all the attacks I could foresee, but I suspect there may be additional risks I haven't accounted for. I would appreciate it if someone could point out any security issues before this goes into production.

I have a file access problem in a self developed daemon process after a setuid() system call. I already post this question to SO but the impression is that the problem is not C++ related but Linux related and so maybe there is someone here who could help me solving it. My daemon program cannot access a configuration file after a setuid(iUid) systemcall even though iUid is owner of the configuration file. Why? I am writing a controller daemon in C++ for home automation which finally will run on an raspberry pi with Raspberry Pi OS. It is started with root permissions as after start it should read an SSL certifacate which only root is granted read access. After the SSL certifacte is read the daemon should switch to user 'pvmonitor' as root permissions are no longer needed. This is done by setuid( iUid ); and I have checked with ps that the process runs as user 'pvmonitor'. The configuration file for this daemon is located at /etc/SmartHome/converd.conf and is owned by user pvmonitor. ls -la /etc/SmartHome/ total 24 drwxrwx---+ 2 pvmonitor www-data 4096 Jul 17 20:07 . drwxr-xr-x+ 107 root root 4096 Jul 17 20:07 .. -rw-r-----+ 1 pvmonitor www-data 705 Jul 17 20:07 coverd.conf The raspberry pi is booted from network and the file system is mounted from a NAS which provides an ACL. Also ACL grants access permission to user pvmonitor: getfacl /etc/ getfacl: Removing leading '/' from absolute path names # file: etc/ # owner: root # group: root user::rwx [...] group::--- group:users:rwx #effective:r-x group:www-data:r-x mask::r-x other::r-x [...] getfacl /etc/SmartHome/ getfacl: Removing leading '/' from absolute path names # file: etc/SmartHome/ # owner: pvmonitor # group: www-data user::rwx [...] user:pvmonitor:rwx [...] group::--- [...] group:www-data:r-x mask::rwx other::--- [...] getfacl /etc/SmartHome/coverd.conf getfacl: Removing leading '/' from absolute path names # file: etc/SmartHome/coverd.conf # owner: pvmonitor # group: www-data user::rw- [...] user:pvmonitor:rwx #effective:r-- [...] group::--- [...] group:www-data:r-x #effective:r-- mask::r-- other::--- In addition the output of stat: stat /etc File: /etc Size: 4096 Blocks: 16 IO Block: 4096 directory Device: 0,22 Inode: 74579976 Links: 107 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2024-12-03 22:14:03.809660810 +0100 Modify: 2025-07-17 20:07:13.645754180 +0200 Change: 2025-07-17 20:07:13.645754180 +0200 Birth: - stat /etc/SmartHome/ File: /etc/SmartHome/ Size: 4096 Blocks: 16 IO Block: 4096 directory Device: 0,22 Inode: 74581572 Links: 2 Access: (0770/drwxrwx---) Uid: ( 1004/pvmonitor) Gid: ( 133/www-data) Access: 2025-07-17 20:06:03.525754180 +0200 Modify: 2025-07-17 20:07:08.395754180 +0200 Change: 2025-07-17 20:35:52.235754180 +0200 Birth: - stat /etc/SmartHome/coverd.conf File: /etc/SmartHome/coverd.conf Size: 705 Blocks: 16 IO Block: 131072 regular file Device: 0,22 Inode: 74581810 Links: 1 Access: (0640/-rw-r-----) Uid: ( 1004/pvmonitor) Gid: ( 133/www-data) Access: 2025-07-17 20:07:08.395754180 +0200 Modify: 2025-07-17 20:07:08.395754180 +0200 Change: 2025-07-18 09:33:38.783696180 +0200 Birth: - With sudo -u pvmonitor less /etc/SmartHome/coverd.conf I can read the configuration file without any problem. But when I try to open the configuration file in my daemon process after the setuid(); command I get an "permission denied" error. Here is a minimum reproducable example which is based on excerpts of my daemons code: #include #include #include #include const char *ptConfigFile = "/etc/SmartHome/coverd.conf"; void printConfig( void ) { std::cout << "Try to open file " << ptConfigFile << std::endl; FILE *ptfTest; ptfTest = fopen( ptConfigFile, "r" ); if (ptfTest != nullptr) { char sLine; while (!feof(ptfTest)) { fgets(sLine,1023,ptfTest); std::cout << sLine; } fclose( ptfTest ); } else perror( "Failed to open file" ); } int main(int argc, char **argv ) { int iUid = 1004; std::cout << "User id is now " << getuid() << std::endl; printConfig(); std::cout << "Switch to user id " << iUid << std::endl; if (iUid == 0 || setuid(iUid)== 0) { std::cout << "User id is now " << getuid() << std::endl; printConfig(); return 0; } std::cerr << "Could not switch user id." << std::endl; return -1; } 1004 is the user id of user pvmonitor. The output of this example is: sudo ./test User id is now 0 Try to open file /etc/SmartHome/coverd.conf CERTFILE=[...] [...] Switch to user id 1004 User id is now 1004 Try to open file /etc/SmartHome/coverd.conf Failed to open file: Permission denied In addition here is the output when I run the test program with strace: sudo strace ./test execve("./test", ["./test"], 0x7fc90538b0 /* 13 vars */) = 0 [...] setuid(1004) = 0 getuid() = 1004 write(1, "User id is now 1004\n", 20User id is now 1004 ) = 20 write(1, "Try to open file /etc/SmartHome/"..., 44Try to open file /etc/SmartHome/coverd.conf ) = 44 openat(AT_FDCWD, "/etc/SmartHome/coverd.conf", O_RDONLY) = -1 EACCES (Permission denied) dup(2) = 3 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) newfstatat(3, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x2), ...}, AT_EMPTY_PATH) = 0 write(3, "Failed to open file: Permission "..., 39Failed to open file: Permission denied ) = 39 close(3) = 0 exit_group(0) = ? What am I doing wrong?

I am using Gentoo, and on my machine at least mount.cifs is not installed suid root by default. In particular, this means that I can't use the user mount option with CIFS shares. I noticed that mount.nfs has suid set. Is there some reason in particular that this is done for CIFS/samba, or is it just Gentoo being overly cautious? If it matters, I am using net-fs/samba and not net-fs/mount-cifs. **More Information:** It seems that historically it was very insecure , however as far back as 2010 the Samba team themselves were happy to reallow suid root access, so is this still an issue? I've tried adding suid to mount.cifs, and it works but I want to get some more information about this if someone is in the know.

In a Podman-in-Podman case, the outer container fails to stop gracefully with SIGTERM when specific capabilities (**cap_setuid** and **cap_setgid**) are set to enable the use of machinectl and inner containers. Without these capabilities, machinectl commands result in errors related to newuidmap and newgidmap. However, with these capabilities set, stopping the outer container requires forcibly using SIGKILL, even after the default timeout, which is not an ideal behavior. why does enabling cap_setuid and cap_setgid interfere with the signal handling mechanism of the outer container? Furthermore, is there a viable solution to facilitate the setup of inner containers without compromising the ability of the outer container to stop gracefully? #### Steps to Reproduce: 1. Run the Outer Container:

podman run -d \
    --name outer-container
    --privileged \
    -v / \

2. Run the Inner Container from the Outer Container:

machinectl shell --uid=user .host /usr/bin/env \
    podman run -t \
    --name inner-container \

3. Attempt to Stop the Outer Container: podman stop outer-container and now observe errors: - Without setcap:

ERRO running /usr/bin/newuidmap 85 0  1 1 100000 65536: newuidmap: write to uid_map failed: Operation not permitted
Error: cannot set up namespace using "/usr/bin/newuidmap": should have setuid or have filecaps setuid: exit status 1

- With setcap:

WARN StopSignal (15) failed to stop container outer-container in 10 seconds, resorting to SIGKILL

Adding cap_setuid+ep and cap_setgid+ep to newuidmap and newgidmap enables the inner container setup but introduces the stopping issue. Impact: -- Without capabilities: Inner containers cannot be managed due to namespace errors. -- With capabilities: The outer container cannot be gracefully stopped using SIGTERM. #### Workaround: The only current workaround is using --stop-signal SIGKILL when running the outer container, which is suboptimal and forces an abrupt termination. #### Environment:

OS Kernel: 4.18.0-553.34.1.el8_10.x86_64
        Podman Version: 4.9.4-rhel
        Container Runtime: crun
        Outer Image: rockylinux:8

##### Expected Behavior: The outer container should gracefully stop with SIGTERM, propagating signals to its processes, regardless of whether cap_setuid and cap_setgid are set. ##### Actual Behavior: SIGTERM fails to stop the outer container, requiring SIGKILL after the timeout. ##### Attempts to Resolve: - Increasing stop-timeout: podman run --stop-timeout=60 ... Outcome: Still fails to stop with SIGTERM after the timeout and resorts to SIGKILL. - Releasing Capabilities Post-Setup: I attempted to revoke cap_setuid and cap_setgid after starting the inner container by setcap cap_setuid-ep /usr/bin/newuidmap and setcap cap_setgid-ep /usr/bin/newgidmap Outcome: Results in the following error when trying to execute machinectl:

ERRO running /usr/bin/newuidmap 83 0  1 1 100000 65536: newuidmap: write to uid_map failed: Operation not permitted

I have a directory of subdirectory and files, with the files' permissions set at 0664. The directory and subdirectories are set at 2775, so all new files made have the same group set as the directory. New files made in the directories have permissions set to 0644. Is there anything that can be done to make new files have the permissions set to 0664 instead, in a similar fashion to using setgid for the group owner of the files?

**Objective** : Run a program as root (C++ binary). The same as : https://unix.stackexchange.com/questions/359598/setuid-bit-not-working-in-ubuntu And : https://unix.stackexchange.com/questions/150972/why-setuid-does-not-work-on-executable ./a.out output: `E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied) E: Unable to lock the administration directory (/var/lib/dpkg/), are you root? psurana //output for "whoami" Look below for the code. ` ls -l output: -rwsrwxr-x 1 root root 46136 Jun 7 20:13 a.out The Code : #include #include int main(int argc, char *argv[]){ std::string input = "apt-get install " + std::string(argv); system(input.c_str()); system("whoami"); return 0; } **Details:** : compiled the program and then did chown root:root a.out && chmod u+s a.out. Please look above for ls -l output. I still do not get the root privileges and the output for system("whoami") in the code is my own username on the machine. Reading the two linked questions did not yield me anywhere. :(. both the creator and the owner of the file are root. The setuid bit is set, so it should work. The filesystem is not external either, it is my own machine. How can I make this work?

I have NICE-DCV installed in RHEL-8.10 and **as root** doing a dcv list-sessions shows all sessions on the system. But if a user does dcv list-sessions then the output from that is only their session and it doesn't report any other session; this is normal. In writing C code in an admin effort to pretty the list-session output, and allow all users to see what active sessions there currently are, I attempted to **setuid** on my /usr/local/bin/dcvlist c executable and it shows as -rwsrwxr-x. 1 root root dcvlist. As root when I run this dcvlist executable I get expected output of all sessions happening but as a regular user account that still does not happen. Am I doing something wrong based on what I explained? Am I mistaken thinking the setuid should also apply to the system("dcv list-sessions") within my C code which it appears not to be? All my C code is doing is system("dcv list-sessions") ... actually a popen and then I'm just reprinting that output. also, the dcv program takes many parameters in addition to list-sessions so I don't want to allow sudo access to allow users to run that as root.

Note that I'm not asking about suEXEC, because the binary must be setuid root, and suEXEC doesn't allow root to execute CGI programs. I need to carry out a one-time configuration during system installation, via Apache. To do this, the client POSTs a request to a setuid root binary (compiled C++, owned by root:root, mode u+s). This almost works: the script does run as root, and modifies system files as required. However, it does *not* return stdout to Apache, so Apache thinks that it dies without producing any headers. Apache's error log contains nothing useful (just the usual 'no headers' message), and the CGI log/debug file also contains nothing useful (it just gives an empty %response, with nothing shown for %stdout or %stderr). I've tested the binary by running it on the server from a script which supplies the required POST data on stdin, and records stdout and stderr. It also runs it under valgrind. However, valgrind can't (easily) run setuid binaries, so I revert the binary to a plain 755 mode, and run the test script as root. In these conditions, the binary performs exactly as expected: valgrind reports no errors, stdout is a valid HTML response with status 200, and stderr contains only the valgrind output. Any insight appreciated.

I'm carrying out a one-off configuration operation which requires a remote client to communicate with a remote server. The client runs Apache, which runs a configure binary, which fetches various scripts from the server with curl. The returned scripts must be run by root. On the client configure is C++ code, and the binary is setuid root (no lectures please, unless you've got a better idea): $ ll /var/www1/cgi-bin/configure -rwsr-xr-x 1 root root 76160 Jul 13 19:20 /var/www1/cgi-bin/configure* The configure code creates a randomly-named directory in /tmp with mkdtemp : # ls -ld /tmp/vs_MYSosq drwx------ 2 root www-data 4096 Jul 13 20:29 /tmp/vs_MYSosq # ll /tmp/vs_MYSosq total 8 drwx------ 2 root www-data 4096 Jul 13 20:29 ./ drwxrwxrwt 25 root root 4096 Jul 13 20:29 ../ The code then execs curl, which retrieves the scripts, but then fails to write them to this directory (it exits with code 23). Any idea why curl can't write to this directory? Is this fixable or do I have to move out of /tmp (which is preferred because it's a ramdisk)? It's presumably a sticky-bit issue, but I can't see how, since the directory is empty and curl isn't attempting to over-write anything.

I have a program ./prog that is owned by root and has the SUID bit set. Permission: -rwsr-sr-x 1 root Then I check the EUID by geteuid() but when I run this (as a user), the output EUID is still my user id, rather than root. What could be the problem?

The info page of command id states that it will output the effective user ID if different from the real user ID. I have been trying to achieve that somehow, running the command with the Bash shell as my normal (unprivileged) user, in Ubuntu. For example, I tried the example in the answer by @Asain Kujovic [here](https://unix.stackexchange.com/a/399349/493379) but it didn't work, I get not euid in the output whatsoever. This is the example:

osbo@osboxes:~/t$ sudo gcc -o test.bin -xc - 
     #include 
     int main() { seteuid(0); system("id"); }
EOF
osbo@osboxes:~/t$ sudo chmod +s test.bin && ./test.bin && sudo rm test.bin
uid=1000(osbo) gid=1000(osboxes) groups=1000(osboxes),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),113(bluetooth),119(scanner)

**EDIT**:
I'm a beginner in Linux, so beginner-friendly answers are welcome, if that is possible for the question I made. I know what is a shell program (like Bash or sh), what are environment variables, what is a C program and what are system calls such as getuid and geteuid. I also know what are real, effective and saved user/group ID, as related to a process a user spawns. Yet, I know very little about parent-child processes scenarios, or the strace command.

I'm implementing some CTF challenges. The flags are in some text files, that get read from the programs. To protect the flags I have changed the owner of the files, but have set the

to the executables to be able to read the files. It works when I run my programs outside gdb, and the flags are read, but inside gdb I get

denied

. I'm running the exercises inside a Linux virutal machine in VirtualBox. I have created a normal user that is not in the sudoers file, and the flags files belong to root.

-rwsr-xr-x 1 root user 15260 Mar 13 13:22  exercise6
-rw-r--r-- 1 user user  3270 Mar 13 06:10 'Exercise 6.c'
-rwsr-xr-x 1 root user 15700 Mar 14 03:28  exercise7
-rw-r--r-- 1 user user  4372 Mar 13 06:10 'Exercise 7.c'

-rwS------ 1 root root 28 Mar 13 06:10 admin_flag.txt
-rwS------ 1 root root 20 Mar 13 06:24 exercise1.txt
-rwS------ 1 root root 27 Mar 13 06:24 exercise2.txt
-rws------ 1 root user 18 Mar 13 10:34 exercise3.txt
-rwS------ 1 root root 22 Mar 13 06:24 exercise4.txt
-rwS------ 1 root root 19 Mar 13 06:10 user_flag.txt

I have two users first being ace and the second being ej ace has a file in its home directory, which is a shell script, with the following permission set ( setuid i have used )

-rwsr--r-x 1 ace ace 15 Jan 20 05:18 /home/ace/myshellscript

the content of script is very simple, listed following

echo "whoami"

cat ./testPrevEsc

but if I try to read another file owned by the the ace (testPrevEsc) which I think i can do by just passing cat filename in the $1, i think i should be able to do it, irrespective of permission that is set for others, as long as the owner can read it, but I can't why ? My understanding of setuid says, that the program or shell executes as its being executed by owner, instead of executing user ( ej in my case), so why cant I read the file and still getting whomai as ej instead of ace ? on the other hand doing sudo whoami works fine it give you root, not the user you are running, I think I'm missing something here.

I have a FreeBSD box running sendmail 8.16. I have several system users (test robots): robot1, robot2 and robot3 and I would like them to be controlled by emails. First of all they should be able to _receive_ emails. So I have the following lines in /etc/mail/aliases: robot1: "| /usr/local/project/script" robot2: "| /usr/local/project/script" robot3: "| /usr/local/project/script" Those robots should process mail in quite the same way, hence the same script is used for them all. The problem is: sendmail always invoke that script with bogus uid 26 (which is "mailnull" special user) for all three recepients. It looks like sendmail daemon downgrades its effective gid/uid on fork, before starting an external script. That's perfectly reasonable, but: The question is: **how do I make sendmail run the script as the respective recepient user**, i.e. as robot1 when the message is for robot1@localhost, as robot2 when the message is for robot2@localhost and as robot3 when the message is for robot3@localhost? Obvious solution is to have three copies of the script, make each copy suid its respective user, and alias each robot user to its copy of the script. That should do the trick, I suppose, but it's kind of ugly. So I wonder if there's some better, more elegant, solution?

Can someone please explain the set-user-ID mechanism in Unix ? What was the rationale behind this design decision? How is it different from effective user id mechanism ?

I did some reading about the difference between real and effective user ID. I thought I understood, but I have a doubt : according to my comprehension, in the example below the command $ id -un should return root as effective user, not jack :

$ sudo cp /usr/bin/bash /usr/bin/bashroot
$ sudo chmod u+s /usr/bin/bashroot
$ ls -l /usr/bin/bashroot 
-rwsr-xr-x 1 root root 1234376 oct.  25 15:42 /usr/bin/bashroot

$ bashroot

$ id -un
jack

$ id -unr
jack

bashroot has setuid and belongs to root, so according to my comprehension I expected $ id -un to return root, not jack. What do I miss ? [EDIT] More specifically, why doesn't /usr/bin/bashroot behave like /usr/bin/passwd, given that both have setuid ?

$ ls -l /usr/bin/passwd 
-rwsr-xr-x 1 root root 63960 févr.  7  2020 /usr/bin/passwd

$ ls -l /usr/bin/bashroot 
-rwsr-xr-x 1 root root 1234376 oct.  25 15:42 /usr/bin/bashroot

$ passwd
Changing password for jack.
Current password:

Then, in another terminal :

$ bashroot

$ ps -a | grep passwd
1682362 pts/3    00:00:00 passwd
$ ps -eo pid,ruid,euid | grep 1682362
1682362  1000     0

$ ps -a | grep bashroot
1682405 pts/4    00:00:00 bashroot
$ ps -eo pid,ruid,euid | grep 1682405
1682405  1000  1000

The effective UID of passwd is root (0), which is expected. Why is the effective UID of bashroot 1000 (jack) and not root ? [EDIT2 : OS]

$ cat /etc/debian_version 
11.6
$ uname -a
Linux d11work 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux
$ bash --version
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)

[EDIT3] See Stephen Kitt's answer :

$ bashroot -p

# id -un
root

# id -unr
jack

According to the [docs](https://man7.org/linux/man-pages/man2/setreuid.2.html) for setreuid: > Unprivileged processes may only set the effective user ID to the real user ID, the effective user ID, or the saved set-user-ID. > Unprivileged users may only set the real user ID to the real user ID or the effective user ID. Why can't we set our ruid to the suid directly? Given that we could first set our euid to the suid and _then_ set the ruid to our new euid, why are we prevented from doing this directly?

I have a sh file (with setuid) that I want specific web users to be able to execute from an endpoint: -rwsr-xr-x 1 root root 59 Sep 11 09:47 restart-workers.sh The content of this file is simply: #!/bin/bash /usr/bin/supervisorctl restart laravel-worker:* When I invoke this: exec('/var/www/html/restart-workers.sh', $stdout, $status); I always get a permission denied error which I expect as PHP-FPM and Nginx are both running as the www-data user, however, I am trying to add the SETUID to the script so when the file is executed, the owner of the file is used to execute the script. Am I invoking this wrong? The sudo package is not installed. > error: , [Errno 13] Permission denied: file: /usr/lib/python3/dist-packages/supervisor/xmlrpc.py line: 557

I am working on an assignment that mainly deals with the following topic: The main idea is to run a program as fakeroot that elevates the privileges of one user to read the file of the owner. If user1 is the owner then fakeroot allows user2 to read user1's file by changing its setuid. I am not able to grasp how it is possible to implement ACLs using setuid. I was under the impression that ACL permission can only be changed using setfacl. I would like to know how one would go about solving this problem. I am fairly new to this domain and any insight would be helpful

I have two files with the following permissions:

-rwsr--r--  1 root root 213 Oct 22 12:15 f1
-r--rwxr--  1 Bob staff 113 Oct 22 12:18 f4

Can the user Bob execute f1 and why? What is the effect of the s in the set of permission on f1?