develooper Front page | perl.perl5.porters | Postings from June 2011

chmod considered harmful on directories

John P. Linderman
June 22, 2011 04:24
chmod considered harmful on directories
Message ID:
If a group of users (sharing a group id) want to share a directory 
hierarchy smoothly, then among the prerequisites are:

   1. A umask of 022 (not 02) should be used, so directories and files
      are writable by others in the group, and
   2. New directories and files must be group-owned by the group, not by
      the primary group of the user who created them.

Item 2 is made easy when /BSD group semantics/ are in effect:  the group 
owning a new directory or file is the same as the group owning the 
directory in which it is created if the user creating it is a member of 
that group (otherwise it is owned by the primary group of the user 
creating it).  In some cases, BSD group semantics are a mount option 
applying to an entire file system, but in many cases (including many 
popular *nix distributions), they are governed by the set-group-ID 
permissions bit (02000) of the containing directory.  In such systems, 
new directories inherit the set-group-ID bit of the parent directory as 
well as its group.  On such systems, /bin/chmod is careful to preserve 
the set-group-ID bit.  Here's a snippet from my man page:

    /chmod preserves a directory's set-user-ID and set-group-ID bits  unless
    you  explicitly  specify otherwise.  You can set or clear the bits with
    symbolic modes like u+s and g-s, and you can set (but  not  clear)  the
    bits with a numeric mode.

The chmod and fchmod system calls are not careful in the same way, and 
therein lies a problem.  Changing the permissions on a directory changes 
*all* the permission bits, including the set-group-ID bit.  CPAN uses 
File::Temp::tempdir to create a secure top-level directory (mode 0700), 
and then it relaxes the security by changing the permissions to 0777 &~ 
umask.  Both operations clear the set-group-ID bit, making it difficult 
for a group to share a perl/CPAN installation.  I filed a bug report on this

but then I got to thinking that the "problem" is likely to turn up in 
many other places, and probably warrants a unified solution.  I checked 
CPAN to see if there was already a module for more gentle treatment of 
directory permission bits, but I didn't see one.  And maybe it belongs 
closer to the core, so installations "do the right thing" for 
directories.  (I think things other than CPAN already work well, but I 
did a find to force all directories to have set-group-ID on and to be 
owned by the shared group, so I can't tell now if they were "right" to 
begin with).

Comments? Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About