From owner-freebsd-current@FreeBSD.ORG Tue Feb 10 02:10:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF58116A4CE for ; Tue, 10 Feb 2004 02:10:25 -0800 (PST) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B58843D1F for ; Tue, 10 Feb 2004 02:10:25 -0800 (PST) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (localhost [127.0.0.1]) i1AAAMZV013838; Tue, 10 Feb 2004 05:10:22 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i1AAAH7F013835; Tue, 10 Feb 2004 05:10:22 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Tue, 10 Feb 2004 05:10:17 -0500 (EST) From: Andre Guibert de Bruet To: Bruce Evans In-Reply-To: <20040208151037.J91658@alpha.siliconlandmark.com> Message-ID: <20040210050623.U91658@alpha.siliconlandmark.com> References: <20040208022417.M91658@alpha.siliconlandmark.com> <20040208151037.J91658@alpha.siliconlandmark.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@freebsd.org Subject: Re: make_dev(9) perms for SCSI & SCSI RAID drivers in CURRENT. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2004 10:10:26 -0000 (Yes, I'm replying to myself... heh) On Sun, 8 Feb 2004, Andre Guibert de Bruet wrote: > On Mon, 9 Feb 2004, Bruce Evans wrote: > > > On Sun, 8 Feb 2004, Andre Guibert de Bruet wrote: > > > > > While studying the various FreeBSD SCSI and SCSI RAID drivers, I noticed > > > that the file mode (perm mask) varies per driver. So far, I've come across > > > 0600, 0640 and 0644. I can't really see why any of these drivers would > > > have anything other than 0600, as it would require root access or at least > > > write perm to do anything useful with the card. > > > > All disk (data) devices should have mode 0640 and ownership root:operator > > and all disk (control) devices should have mode 0600 and ownership root:wheel. > > Distributed setting of ownerships and permissions gives many more bugs than > > centralized setting in MAKEDEV. Mode bugs in devfs start at its top level > > (its directory has mode 555 although its owner can write to it except > > possibly in the jailed case). > > > > > Here's a quick illustration of what I'm refering to: > > > > > > aac 0640 (octal notation in code) > > > amr 0600 (implemented as S_IRUSR | S_IWUSR) > > > asr 0640 (octal notation in code) > > > ciss 0600 (implemented as S_IRUSR | S_IWUSR) > > > ida 0600 (implemented as S_IRUSR | S_IWUSR) > > > iir 0644 (implemented as S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) > > > ips 0600 (implemented as S_IRUSR | S_IWUSR) > > > isp 0600 (octal notation in code) > > > mly 0600 (implemented as S_IRUSR | S_IWUSR) > > > > Most of these actually create control devices, so mode 0600 is correct > > and group operator is bogus, and mode 0640 is a potental security hole > > especially with group operator. Group operator is almost always used > > of course. The data devices are mostly created by the disk mini-layer > > in RELENG_4 (except RELENG_4 doesn't really have devfs) and by GEOM in > > -current. > > I adjusted and expanded the set of patches that I had to change > permissions on the control devices so that they also set the GID to wheel. > The assumption that I am making with these patches is that the drivers > that are calling make_dev() are creating control devices, as they should > be letting GEOM create their data devices. Feedback is welcome here as my > GEOM-fu isn't all that hot... > > I have tried to maintain the style used in the drivers themselves and > fixed the long line in the patch for isp_freebsd.c. I've gotten a number of interesting questions and so far no objections. Is there any chance of getting the patches committed? Regards, Andy > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/ >