There is a very obvious bug when attempting to set SGID on a directory when you are not a member of the group that has ownership on that directory. For example, follow along with me in the following example on your box:
[Wed 08/01/30 06:55 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 162 % mkdir ~/tmp [Wed 08/01/30 06:56 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 163 % ls -ld ~/tmp drwxr-xr-x 2 aaron aaron 4096 2008-01-30 06:56 /home/aaron/tmp [Wed 08/01/30 06:56 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 164 % sudo -i Password or swipe finger: root@kratos:~# chown .root /home/aaron/tmp/ root@kratos:~# exit logout [Wed 08/01/30 06:57 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 165 % ls -ld ~/tmp drwxr-xr-x 2 aaron root 4096 2008-01-30 06:56 /home/aaron/tmp
So far, all we've done is create a directory in your home named 'tmp'. We showed that your User Private Group is the group owner of the directory. As such, we elevated ourselves to root, and changed group ownership of that directory to root, and showed it as thus at the end. On a side note, you can tell I'm on a Debian-based system, as my umask is set to 0022 by default, rather than the more sane 0002 with the User Private Group scheme in place.
Now, at this point, I'm going to assume that your unprivileged account is not a member of the root group. If it is, the remainder of this exercise will not work for you. Also, one may question the integrity of your choice putting your account in the root group. However, the point of this exercise is to show a bug with how SGID works on directories that you do not have group access to. Let's continue:
[Wed 08/01/30 07:01 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 166 % chmod g+s ~/tmp [Wed 08/01/30 07:03 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 167 % ls -ld ~/tmp drwxr-xr-x 2 aaron root 4096 2008-01-30 06:56 /home/aaron/tmp
Wait a minute. Shouldn't the permissions be 'drwxr-sr-x'? Actually, no. The results above are expected. Setting SGID on a directory is a special permission. If you are not a member of the group that owns the directory, then you can't set the SGID bit. Makes sense, just like you can't change the group of the directory to a group that you are not a member of. Just because you own the directory, doesn't give you total control over it.
Ok, so if the expected behavior is what we see above, then you're probably asking "Where's the bug?". Follow along with me on last time:
[Wed 08/01/30 07:03 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 168 % chmod g+s ~/tmp [Wed 08/01/30 07:06 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4] <aaron@kratos:~> zsh 169 % echo $? 0
First off, as we noticed above, it's not setting SGID. So, if not, it should be sending a message, such as "Permission denied" to STDERR. However, there is no such error message. Further, look at the exit status code. What's this? The exit code of chmod g+s is 0, meaning it succeeded (as shown by echoing the special variable '$?'). It did? It successfully set SGID? Not from what I can tell. So, not only is it not displaying an error to screen, it's returning the wrong exit code!
I don't know about you, but this is a BIG bug. Who's maintaining the 'coreutils' package and can this bug, as well as the cp bug mentioned in my previous post, get fixed? I'll post this to Launchpad.
{ 7 } Comments