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

user private groups and a src group

   Date: Tue, 22 Mar 94 11:34 PST
   From: Andrew Repton <andy@pteron.demon.co.uk>

   Firstly let me say that we are considering this proposal at work as it
   appears to solve our problems regarding project access.

   During the consideration an interesting point was raised. Our network is
   soon to be on the Internet. It has been stated elsewhere that it is a
   *BAD THING* to have as default world readable files, as this allows
   potential hackers (in the newspaper sense of the word) access to 
   information that could be used in their hacking. The 'traditional' way
   around this would be to place our local users in a local group, so that
   they can read the necessary files and make the umask 027. If we use the
   proposal then the above does not work. So what is the best way of
   approaching the problem of giving read access to local users whilst
   keeping out non-local users?

Depending on what you want, you can make the default group of all users be
the "users" group, but you will have to make home directories
setgid=<private group>.  This would allow you to use James Bond's umask
(007) as the default.  Non-local users would have no access to any files by
default.  Local users would create files with group read/write access by
default.  In home directories, the created files will allow no access by
other users (even local ones) because they will get the <private group> by
default.  In project directories (setgid=<project group>), the created
files will allow read/write access by the project group by default.
Outside of project or home directories, the created files will be
readable/writable only by local users.  This last bit may not be what you
want, but that's what you get when you reassign the "other" permission bits
to control worldwide access.  (There are only three access levels,
afterall... two really; the "owner" bits aren't much use for mediating
access by groups of people unless you're going to get everyone to do a lot
of su'ing to change their uids.)

After saying all that, I should ask whether this kind of worldwide
accessibility is really a good idea.  The traditional technique for
"keeping out non-local users" is not to let them in, or at least to limit
the extent to which you let them in.  FTP servers traditionally chroot to
~ftp/ for anonymous users and / is not normally exported as an NFS mount
point.  With worldwide accessibility, your only protection from non-local
hackery is diligence on the part of every local user.  I would worry about
people using old ~/.profile's with permissive umasks, or other ways to get
it wrong.  Hopefully, you've educated the local users about the change in
the meaning of the "other" bits -- i.e. now they control read access by any
other user in the _world_, not just the machine.

Matthew Birkholz

Reply to: