Linux – Howto prevent chgrp from clearing “setuid bit”

chgrplinuxsetuid

We have RH based Linux images; on which I have to "apply" some "special archive" in order to upgrade them to the latest development version of our product.

The person creating the archive figured that within our base image, some permissions are wrong; so we were told to run

sudo chgrp -R nobody /whatever

We did that; and later on, when our application is running, obscure problems came up.

What I found later on: the call to chgrp will clear the setuid bit information on our binaries within /whatever.

And the actual problem is: some of our binaries must have that setuid bit set in order to function properly.

Long story short: is there a way to run that "chgrp" command without killing my setuid bits?

I just ran the following on my local Ubuntu; leading to the same result:

mkdir sticky
cd sticky/
touch blub
chmod 4755 blub 
ls -al blub

–> shows me file name with red background –> so, yep, setuid

chgrp -R myuser .
ls -al blub

–> shows me file name without red background –> setuid is gone

Best Answer

If you want to implement your chgrp -R nobody /whatever while retaining the setuid bit you can use these two find commands

find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
                                      -exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +

The find ... -perm 04000 option picks up files with the setuid bit set. The first command then applies the chgrp and then a chmod to reinstate the setuid bit that has been knocked off. The second one applies chgrp to all files that do not have a setuid bit.

In any case, you don't want to call chgrp or chmod on symlinks as that would affect their targets instead, hence the ! -type l.

Related Solutions

Understanding Root Owned Programs with Setuid Bit

ping needs root so it can open a socket in raw mode. That's literally the first thing it does when it starts up:

icmp_sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);
socket_errno = errno;

That's the only thing it needs root for, so like many programs, it immediately drops its privilege level back to your normal user account:

uid = getuid();
if (setuid(uid)) {
    perror("ping: setuid");
    exit(-1);
}

Linux Bash Setuid – Setuid Bit Seems to Have No Effect on Bash

The explanation is kind of annoying: bash itself is the reason. strace is our friend (must be SUID root itself for this to work):

getuid()                                = 1000
getgid()                                = 1001
geteuid()                               = 0
getegid()                               = 1001
setuid(1000)                            = 0
setgid(1001)                            = 0

bash detects that it has been started SUID root (UID!=EUID) and uses its root power to throw this power away, resetting EUID to UID. And later even FSUID, just to be sure...:

getuid()                                = 1000
setfsuid(1000)                          = 1000
getgid()                                = 1001
setfsgid(1001)                          = 1001

In the end: no chance. You have to start bash with UID root (i.e. sudo).

Edit 1

The man page says this:

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

But this does not work for me. -p isn't even mentioned among the startup options. I also tried --posix; didn't work either.

Best Answer

Related Solutions

Understanding Root Owned Programs with Setuid Bit

Linux Bash Setuid – Setuid Bit Seems to Have No Effect on Bash

Related Question