Image of the glider from the Game of Life by John Conway
Skip to content


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]
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]
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]
zsh 164 % sudo -i
Password or swipe finger: 
root@kratos:~# chown .root /home/aaron/tmp/
root@kratos:~# exit
[Wed 08/01/30 06:57 MST][pts/1][x86_64/linux-gnu/2.6.22-14-generic][4.3.4]
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]
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]
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]
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]
zsh 169 % echo $?

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

  1. Byron Clark | January 30, 2008 at 8:45 am | Permalink

    The chmod command isn't reporting an error because the chmod syscall isn't reporting an error. You can verify this by running the chmod command under strace and grepping for the chmod syscall.

  2. Byron Clark | January 30, 2008 at 9:05 am | Permalink

    Turns out this behavior is documented, just not where you may think. From chmod(2):

    If the calling process is not privileged (Linux: does not have the
    CAP_FSETID capability), and the group of the file does not match the
    effective group ID of the process or one of its supplementary group
    IDs, the S_ISGID bit will be turned off, but this will not cause an
    error to be returned.

  3. Aaron | January 30, 2008 at 9:15 am | Permalink

    Hmm. Still a bug, though. If the user is not notified to the behavior of a process and it is not logged, then in my book, that definitely qualifies as a bug. How else would the user know what is happening when the bit is not set?

  4. ThaddeusQ | January 30, 2008 at 11:05 am | Permalink

    A bug is when something happens that is not expected behavior. This is expected behavior as evidenced by the documentation. Just because it doesn't match your expectations doesn't make it a bug. Just my 2 cents worth.

  5. . | January 30, 2008 at 12:02 pm | Permalink

    A document bug is not a bug anymore, it's a feature =).

  6. Aaron | January 31, 2008 at 7:00 am | Permalink

    @ThaddeusQ- Regardless of how remote the documentation is, if it exists, it's not a bug any longer? Don't you find that a little absurd? Also, couldn't it be argued that this is unexpected behavior? Certainly, the user who discovers this will be wondering what's going on, and call me crazy, but I doubt they'll pull up the dev man pages to figure it out.

  7. Josh | August 18, 2008 at 7:40 am | Permalink

    Sorry to bump an old-ish thread, but I ran into this exact same issue. I created a directory, created a new group with the users I wanted to be able to access the directory, set the permissions to 770 on the directory, then tried to chmod g+s the directory and got no error. I'm actually part of the group in question, but it still wouldn't let me do it.

    I think the bottom line on the "bug vs not bug" conversation is this:
    You ran the command to set the sgid permission to g+s. Expected behavior is that when you ls -a, you see s (or S if you don't have +x) in the "group execute" / "sgid" column of the file permissions. That, or you get an "operation not permitted" error just like if you try to change a permission to something you don't own.

    Just because a bug is documented doesn't mean it's not still a bug. Case in point: The Microsoft Knowledge Base.

Post a Comment

Your email is never published nor shared.