When creating a file, open()/creat() allows the setgid bit to be set via the mode argument even when, due to the bsdgroups mount option or the file being created in a setgid directory, the new file's group is one which the user is not a member of. The user can then use ftruncate() and memory-mapped I/O to turn the new file into an arbitrary binary and thus gain the privileges of this group, since these operations do not clear the setgid bit.
Created attachment 11377 [details] Python script to reproduce When run in a setgid directory, this should produce a copy of /usr/bin/id that is setgid to the directory group, regardless of whether the user belongs to it. I've verified this on the ext2, ext3, ReiserFS, XFS, JFS and tmpfs file systems.
I believe this was fixed in : commit 7b82dc0e64e93f430182f36b46b79fcee87d3532 Author: Linus Torvalds <torvalds@woody.linux-foundation.org> Date: Tue May 8 20:10:00 2007 -0700 Remove suid/sgid bits on [f]truncate() .. to match what we do on write(). This way, people who write to files by using [f]truncate + writable mmap have the same semantics as if they were using the write() family of system calls. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> If you concur please close? Thanks, -Eric
(In reply to comment #2) > I believe this was fixed in : > > commit 7b82dc0e64e93f430182f36b46b79fcee87d3532 > Author: Linus Torvalds <torvalds@woody.linux-foundation.org> > Date: Tue May 8 20:10:00 2007 -0700 > > Remove suid/sgid bits on [f]truncate() Thanks Eric. I have tested this. This patch fixes the problem, and prevents the possible disclosure of privileged information. Thanks, Eugene