bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in chgrp (GNU fileutils) 4.0p


From: Bob Proulx
Subject: Re: Bug in chgrp (GNU fileutils) 4.0p
Date: Sun, 3 Dec 2000 23:42:14 -0700 (MST)

> I have found a bug in chgrp (GNU fileutils) 4.0p.
> 
> When changing the group of a file that is has the suid bit set, it removes
> the suid bit when changing the group.
> 
> Example:
> 
> # ls -l wrapper
> -rwsrwxr-x    1 root     users       15035 Dec  1 13:24 wrapper
>    ^ suid bit is set
> 
> # chgrp majordom wrapper
> 
> # ls -l wrapper
> -rwxrwxr-x    1 root     majordom    15035 Dec  1 13:24 wrapper
>    ^ suid bit was removed
> 
> This is clearly a bug as chgrp should only be modifying the group of a
> file and not touching the permissions.
[...]
> I just realized that I should have given more information.  I was running
> this command as root.  Given the above information about appropriate
> privileges, I would think root would have all privileges and would not be
> subject to this condition.  Is clearing of this bit something that chgrp
> does or something that my kernel would handle?  I'm using Linux kernel
> 2.3.99-pre8 on a Red Hat system.

I was able to recreate your bug case on Linux.  Note that both HP-UX
and AIX worked as expected and suid bit was not cleared with either of
those operating systems.  Here is my test frame I used to recreate
this problem.

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

int main()
{
  system("rm -f foo");
  system("touch foo");
  system("chgrp 0 foo");
  system("chmod g-w,a+x,u+s foo");
  system("id");
  system("ls -l foo");
  if (lchown("foo",(uid_t)-1,2) < 0)
    {
      perror("lchown");
      exit(1);
    }
  system("ls -l foo");
  return 0;
}

address@hidden /tmp]$ sudo ./chgrp-test
-rwsr-xr-x    1 bob      bob             0 Dec  3 23:15 foo
uid=0(root) gid=0(root) groups=500(bob)
-rwxr-xr-x    1 bob      daemon          0 Dec  3 23:15 foo

I tested this on a linux 2.2.14 kernel and a 2.0.27 kernel and both
behaved the same.  (Except in the older kernel I used chown instead of
lchown.)  Note that the kernel system call lchown causes the suid bit
to be unset.

I believe this to be a bug in the linux kernel.  This is not a problem
with the fileutils package nor is there really anything the fileutils
software can do about this problem.  It works the best that the
underlying operating system allows it to work on each platform.

I suppose it might be possible to add in code that saves and restores
the suid-bit.  But that code would only be needed on linux and not on
other platforms.  It really seems like an ugly workaround to me when
the problem really should be fixed in the kernel.  It would not be
possible to detect that at configure time since the only way to detect
it is to run as root and generally building packages as root should be
avoided.  Hmm...

Bob Proulx



reply via email to

[Prev in Thread] Current Thread [Next in Thread]