From owner-freebsd-security  Sun May  5 07:10:10 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA18361
          for security-outgoing; Sun, 5 May 1996 07:10:10 -0700 (PDT)
Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA18356
          for <freebsd-security@FreeBSD.ORG>; Sun, 5 May 1996 07:10:03 -0700 (PDT)
Received: (from alex@localhost) by zen.nash.org (8.7.5/8.6.12) id JAA01310; Sun, 5 May 1996 09:04:49 -0500 (CDT)
Date: Sun, 5 May 1996 09:04:49 -0500 (CDT)
Message-Id: <199605051404.JAA01310@zen.nash.org>
From: Alex Nash <alex@zen.nash.org>
To: jarekb@pap.waw.pl
Cc: freebsd-security@FreeBSD.ORG
Subject: dot.cshrc and weird umask value
Reply-to: nash@mcs.com
Sender: owner-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Can anyone tell me why on FreeBSD (the same with BSD/OS) there is the umask
> value 2 ???? This simply couses producing group writable files. Imagine the
> person which created .forward file, anyone in his group can modify this to
> reforward files or duplicate mails. 
> 
> This is in /usr/share/skel/dot.cshrc. I know that everyone can set proper
> value of umask but some not experienced users do not know about it. And even
> experienced administrators belive that the distribution skeleton files are
> good enough to copy then into user directory. Is there a reason for this ????

The man page for adduser(8) has a good writeup on this:

  UNIQ GROUP
     Perhaps your missing what *can* be done with this scheme that falls apart
     with most other schemes.  With each user in his/her own group the user
     can safely run with a umask of 002 and have files created in there home
     directory and not worry about others being able to read them.

     For a shared area you create a separate uid/gid (like cvs or ncvs on
     freefall), you place each person that should be able to access this area
     into that new group.

     This model of uid/gid administration allows far greater flexibility that
     lumping users into groups and having to muck with the umask when working
     in a shared area.

     I have been using this model for almost 10 years and found that it works
     for most situations, and has never gotten in the way.  (Rod Grimes)

Alex