when the group of a file that is setgid is changed, the setgid bit should be removed (says solar, and also the comments in chown_common() in sys_fs/open.c). however, on x86 running 2.4.23-aa1: # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test -rwxr-sr-x 1 root root 0 Dec 14 03:59 test -rwxr-sr-x 1 root utmp 0 Dec 14 03:59 test and on x86 running 2.6.0-test11-gentoo-r1: -rwxr-sr-x 1 root root 0 Dec 13 22:46 test -rwxr-sr-x 1 root utmp 0 Dec 13 22:46 test oddly 2.6.0-test10-benh1 running on ppc seems to do the right thing: # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test -rwxr-sr-x 1 root root 0 Dec 14 08:06 test -rwxr-xr-x 1 root utmp 0 Dec 14 08:06 test so is this code non-functional on x86? or is it wrong on ppc? also note, on a x86 redhat 6.2 box running 2.2.19-6.2.16: # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test -rwxr-sr-x 1 root root 0 Dec 14 04:08 test -rwxr-xr-x 1 root utmp 0 Dec 14 04:08 test
on a ppc running 2.4.22-ben2: # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test -rwxr-sr-x 1 root root 0 Dec 14 01:24 test -rwxr-xr-x 1 root utmp 0 Dec 14 01:24 test (this is the expected result).
Can you try the latest vanilla * prepatch * sources for both 2.4 and 2.6? If they both give this, I'd really recommend sending this upstream. This does look like a X86 problem of some sort.
scox has tracked this down to be a bug in CHOWN(1) I'll ask him to paste his example code in here which shows this as well as his recomendations.
I've added some debug code to chown_common(), and the modes seem to be accurate before and after notify_change() is called. By stracing CHOWN(1), i've noticed the following : 4374 chown32("test", 1000, 10) = 0 4374 chmod("test", 0102654) = 0 In fact, it seems that CHOWN(1) sets the original stored modes just after calling sys_chmod(). I wrote up a little application that calls sys_chown(), and the setuid/setgid flags were correctly removed, so this seems to be a coreutils' chown issue (feature?). In my opinion, CHOWN(1) shouldn't touch at kernel set flags, so we should either remove the chmod() call from it, or make it remove setuid/setgid modes (the first solution is preferable). Maybe we need some input from the coreutils guys.
Rajiv: Can you get the "chown --version" for each of your results?
versions, corresponding to the output shown above: on x86 running 2.4.23-aa1: chown (coreutils) 5.0 on x86 running 2.6.0-test11-gentoo-r1: [unknown, was not my machine] on ppc running 2.6.0-test10-benh1: chown (coreutils) 5.0.91 on a x86 redhat 6.2 box running 2.2.19-6.2.16: chown (GNU fileutils) 4.0p on a ppc running 2.4.22-ben2: chown (coreutils) 5.0.91 and brad_mssw adds this... note that the behavior below is correct (setgid bit gets removed): 02:29 <brad_mssw> laptop root # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test; chown --version 02:29 <brad_mssw> -rwxr-sr-x 1 root root 6653 Dec 18 02:28 test 02:29 <brad_mssw> -rwxr-xr-x 1 root utmp 6653 Dec 18 02:28 test 02:29 <brad_mssw> chown (coreutils) 5.0.91 02:29 <brad_mssw> Written by David MacKenzie. 02:29 <brad_mssw> on 2.6.0-test10-gentoo-r1 02:30 <brad_mssw> amd64 root # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test; chown --version 02:30 <brad_mssw> -rwxr-sr-x 1 root root 0 Dec 18 02:51 test 02:30 <brad_mssw> -rwxr-xr-x 1 root utmp 0 Dec 18 02:51 test 02:30 <brad_mssw> chown (coreutils) 5.0.91 02:30 <brad_mssw> Written by David MacKenzie. 02:30 <brad_mssw> on 2.6.0-gentoo
coreutils-5.0-r6 WRXsti linux-2.6-bk # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test; chown --version -rwxr-sr-x 1 root utmp 0 Dec 18 01:44 test -rwxr-sr-x 1 root utmp 0 Dec 18 01:44 test chown (coreutils) 5.0 Written by David MacKenzie. coreutils-5.0.91-r2 WRXsti linux-2.6-bk # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test; chown --version -rwxr-sr-x 1 root utmp 0 Dec 18 01:47 test -rwxr-sr-x 1 root utmp 0 Dec 18 01:47 test chown (coreutils) 5.0.91 Written by David MacKenzie.
even weirder, I opened a new terminal, and: WRXsti root # touch test; chmod 2755 test; ls -l test; chown root:utmp test; ls -l test; chown --version -rwxr-sr-x 1 root root 0 Dec 18 01:50 test -rwxr-xr-x 1 root utmp 0 Dec 18 01:50 test chown (coreutils) 5.0.91 Written by David MacKenzie.
Could you also strace chown and see if chmod is called ?
Yes it does. ... lstat64("test", {st_mode=S_IFREG|S_ISGID|0755, st_size=0, ...}) = 0 chown32(0xdffffb74, 0, 0x196) = 0 exit_group(0) = ? I also figured out the weirdness I was having. You have to make sure you rm test before running those steps ;) Silly me.
sorry misread that, no chmod is not called with coreutils-5.0.91
Okay, then we can conclude that it's a coreutils 5.0 issue and that it has been fixed on coreutils 5.0.91
coreutils-5.0.91-r4 needs A LOT of testing, because I'd really like to make it arch stable on x86 before Friday's portage snapshot for GRP
coreutils-5.0.91-r4.ebuild is in stable
