From owner-freebsd-current Mon May 15 14:15:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA16636 for current-outgoing; Mon, 15 May 1995 14:15:24 -0700 Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA16622 for ; Mon, 15 May 1995 14:15:12 -0700 Received: (from mark@localhost) by linus.demon.co.uk (8.6.11/8.6.9) id WAA02447; Mon, 15 May 1995 22:14:31 +0100 Date: Mon, 15 May 1995 22:14:31 +0100 From: Mark Valentine Message-Id: <199505152114.WAA02447@linus.demon.co.uk> In-Reply-To: Bruce Evans's message of May 15, 9:09am X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bruce Evans , current@FreeBSD.org Subject: Re: MAKEDEV and device permissions Sender: current-owner@FreeBSD.org Precedence: bulk > From: Bruce Evans > Date: Mon 15 May, 1995 > Subject: Re: MAKEDEV and device permissions > >MAKEDEV seems to be a bit confused about how to set the permissions > >on several devices (e.g. fd*). It temporarily uses a less restrictive > >umask than the one it starts off with, but then chmods the devices > >to be more restricted anyway. In the case of joy*, it doesn't set > >the umask back. (Apart from this last bit, the problem is only one > >of internal consistency.) > > >Suggested fix: (policy) decide which one is right. Make the chmod > >calls agree, and remove the umask adjustments. > > I've been changing it the other way, to use umask consistently. > MAKEDEV is very slow, and umask is much faster than chmod. I would agree with the performance argument if it were significant or if there were no other factor involved. However, in my opinion it's more important to make scripts like MAKEDEV as obvious as possible to reduce the chance that security holes creep in. I find it easier to read device modes directly than having to work out octal complements on the fly. Rod showed me a candidate patch which seemed to confuse umasks with modes (in favour of modes :-), which resulted in some calls to "umask 37" and some to "umask 026" to do the same thing... > Tapes were always supposed to be operator-writeable. This will be fixed > in 2.0.5. I have the raw floppy operator-writeable locally too, but I > don't think it is right for general use because floppies can be mounted. I miss the point here. Only root can mount/umount. Is there a problem with the operator writing to a device containing a mounted file system? I thought that type of thing was already prohibited by the kernel. Mark.