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

NEW PROPOSAL



 
I would like to present a new idea for 'private groups'.
 
First, I'd like to give my understanding of the situation to be sure I
have it completely right.
 
Typical system:
  /home
  /home/fred (fred,users)
  /home/jack (jack,users)
  /home/jill (jill,users)
  /home/proj (root,proj)
 
jack and jill are members of "proj". If they want to work in the
/home/proj directory, they can type "newgrp proj".
 
If they leave their umask at one value (022, 020, 002, 007) for both
their home directories and /home/proj, then fred can read (and
possibly write) to their home directories through the "users" group.
 
To avoid this, jack and jill have to remember to set the umask to the
appropriate value every time they change working directories.
 
The current proposal:
  /home
  /home/fred (fred,fred)
  /home/jack (jack,jack)
  /home/jill (jill,jill)
  /home/proj (root,proj)
 
Accessing the /home/proj directory remains unchanged.
 
Providing users with their own groups allows them to leave the umask
set at one value since they are the only member of their own group.
 
This prevents fred from using the group permissions to access jack or
jill's files, whilst still letting them share files in the project
directory (without stuffing around with umask).
 
My proposal:
  /home
  /home/fred (fred,private)
  /home/jack (jack,private)
  /home/jill (jill,private)
  /home/proj (root,proj)
 
Accessing the /home/proj directory remains unchanged.
 
Users are listed in /etc/passwd as being in the group "users", the
same as the "Typical system" above. The group "private" is listed in
/etc/group with no members.
 
Files created in users home directories will have the group ownership
of "private". Since nobody belongs to the "private" group, fred
cannot use the group permissions to access jack or jill's files.
 
It isn't necessary to belong to a group for that group ownership to
be inherited from the parent directory. This is the point that makes
my proposal possible.
 
This arrangement with the single "private" group eliminates the need
to have a group per user, and therefore eliminates the need to
synchronise /etc/password and /etc/group with a scheme like uid=gid.
 
This in turn eliminates the extra problems with NFS mounting and most
of the other objections that have been raised against private groups,
whilst still retaining the same usage and all the benefits that
private groups offered.
 
Furthermore, someone has been very clever and prevented chmod from
setgid'ing a file if you do not belong to the group (even if you do
own the file). This eliminates that possible security hole.
 
Any comments?
 


Reply to: