setgid + execute unix flag and files

Marcelo Andrade · 03-18-2011, 05:50 PM

Heya.

I'm writing this about a peculiarity of the activation of both SETGID bit plus EXECUTE bit as unix permissions on FILES (not directories).

It's well known that setting setgid bit on executable programs make that program to be run with the program's gid as effective gid, instead of the user who executed. Allright, no discussion here.

But that also makes the files with those specific permission set 'protected' against copying something that overwrites them, or even simple editing.

I believe you can reproduce this easily on any Linux:
File teste, with unix permissions set as 2770, group owner vboxusers:

Code:

# ls -lan
-rwxrws--- 1 root vboxusers 0 2011-03-17 20:05 teste

I'll use the user USUARIO for this test, which is part of vboxusers group:

Code:

# id USUARIO
uid=USUARIO(123) gid=888(grupo),131(vboxusers)

# su USUARIO

If I try to overwrite the file, or copy something else over it, I get errors:

Code:

$ echo 'texto' > teste
teste: Operation not permited

$ cp /tmp/teste ./
cp: not possible to create common file `./teste': Operation not permited

I can remove the file normally if I want:

Code:

$ rm -v teste
removed `teste'

I believe since of the innate 'danger' of setuid/setgid, this is some kind of colateral 'protection' on the setgid files.

Question is: who implements this? In the system call? Also: is this a well known behaviour? Because I very much looked everywhere and I see no mention to this. Of course I'm not english native, so maybe I'm looking for the wrong keywords. But anyways, anyone ever seen this?

bhaslinux · 03-20-2011, 03:14 AM

Although you belong to the vboxusers group, you still are not running as that group.
Can you try
$ newgrp vobxusers

and then repeat your test ?

Marcelo Andrade · 03-21-2011, 07:08 AM

Quote:

Originally Posted by bhaslinux

Although you belong to the vboxusers group, you still are not running as that group.
Can you try
$ newgrp vobxusers

and then repeat your test ?

I take you mean by the su. But yeah, this is just a simulation on what happened.

Anyways, I did it as you asked, using newgrp, and still same result.

Just as a sidenote: I'm not trying to 'fix' it, since to be able to overwrite the file all I have to do is to chmod g-s file and it goes back into working as intended. Just trying to figure out what's happening.

For instance, an strace of the copy command trying to overwrite the file gives me the following:

Code:

# strace cp something file
...
open("teste", O_WRONLY|O_TRUNC|O_LARGEFILE) = -1 EPERM (Operation not permitted)
...