[1167] in bugtraq
Re: set group id on directories
daemon@ATHENA.MIT.EDU (smb@research.att.com)
Fri Mar 3 11:53:33 1995
From: smb@research.att.com
To: blymn@awadi.com.AU (Brett Lymn)
Cc: marc@tky.icdc.fr (Marc Samama), bugtraq@fc.net
Date: Fri, 03 Mar 95 09:34:52 EST
>On my system, whereas the manual states that this bit is ignored on
>directories, a file created on such a directory is owned by the same
>group that posses the dir, and any child directory has the same sgid
>bit, by default.
This is normal behaviour on the Suns (and I think it's documented
somewhere)
It isn't a priori a security hole; nevertheless, there may be security
implications.
In the Elder Days, processes were in exactly one group at a time, and
directories were created with the permissions of the effective gid of
the process that issued the mkdir(). Berkeley changed that in 4.2bsd
to let processes be in more than one group simultaneously. Both to
settle the question of what group new files and directories should be
in, and also to make the semantics useful, they also decreed that new
files should inherit the gid of the directory in which they were created.
When Sun and USL got together to merge the SysV/BSD strains of UNIX,
this difference in file system semantics was one of the issues that had
to be resolved. Someone decided that the setgid bit for a directory
could be given a useful meaning, thereby letting administrators and users
decide for themselves which semantics they wanted. But no attempt was
made to see which programs, if any, would break with either behavior.
There was thus mechanism but no grounds for choosing a policy. I protested
this at the time, but no one listened.
Security implications could arise if a setgid() program created a file
or directory under the wrong assumption about who would have permissions
on that file. This is most likely to occur with programs that originated
on the System V side of the world. I should add, btw, that I don't know
of any such holes, but I wouldn't be surprised if some were to appear.
