From owner-freebsd-current  Mon May 15 23:02:05 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id XAA29896
          for current-outgoing; Mon, 15 May 1995 23:02:05 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA29888
          for <current@freebsd.org>; Mon, 15 May 1995 23:02:00 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA23449; Tue, 16 May 1995 15:58:01 +1000
Date: Tue, 16 May 1995 15:58:01 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199505160558.PAA23449@godzilla.zeta.org.au>
To: bde@zeta.org.au, current@FreeBSD.org, mark@linus.demon.co.uk
Subject: Re: MAKEDEV and device permissions
Sender: current-owner@FreeBSD.org
Precedence: bulk

>I can still think of messy bits such as where control devices are created
>with different permissions from the standard devices.  Do you default the
>standard devices to rely on the umask, yet use chmod for the control
>devices?  Do you set another temporary umask for the control devices
>(unlikely)?  Without explicit chmods for everything, these places at
>least need a comment saying "I know what I'm doing here".

I want to use chmod only for the special [control] devices (probably
including the miscellaneous `std' devices).  Use of chmod then acts as
a warning that you are doing something special.

Do you think it is worth worrying about the following?

	umask 006
	mknod foo c x y
			<----- window where group can read and write
			<--,
	chmod 600 foo	   |-- window where group may be wrong
			<--'
	chgrp baz foo

The umask would have to be at least 066 all the time to avoid these
holes.  The 2.0R MAKEDEV doesn't worry at all about this.  It has
umask 2's followed by chmod 640's for almost all disk devices.

Bruce