From owner-freebsd-security Sun May 5 16:57:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA20002 for security-outgoing; Sun, 5 May 1996 16:57:36 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA19996 for ; Sun, 5 May 1996 16:57:31 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA02210; Sun, 5 May 1996 14:03:02 -0700 From: "Rodney W. Grimes" Message-Id: <199605052103.OAA02210@GndRsh.aac.dev.com> Subject: Re: dot.cshrc and weird umask value To: nlawson@kdat.csc.calpoly.edu (Nathan Lawson) Date: Sun, 5 May 1996 14:03:02 -0700 (PDT) Cc: nash@mcs.com, security@freebsd.org In-Reply-To: <199605051602.JAA20318@kdat.calpoly.edu> from Nathan Lawson at "May 5, 96 09:02:39 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 ???? > > > > UNIQ 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) > > Unfortunately, this solution does not scale well to an enterprise-wide > network as your groups file grows ever larger. Remember it's not hashed like > the pwd.db, and that's reason enough for me to have modified adduser to not > support that scheme. If your using this interprise wide you should be using NIS, if your using NIS your group file is hashed by NIS. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD