From owner-devfs@oss.sgi.com Mon Sep 3 21:02:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8442o509445 for devfs-outgoing; Mon, 3 Sep 2001 21:02:50 -0700 Received: from inf.ufrgs.br (puma.inf.ufrgs.br [143.54.11.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8442ld09442 for ; Mon, 3 Sep 2001 21:02:47 -0700 Received: from jacui (jacui [143.54.11.130]) by inf.ufrgs.br (8.11.0/8.11.3) with ESMTP id f8440VA05888 for ; Tue, 4 Sep 2001 01:00:32 -0300 Date: Tue, 4 Sep 2001 01:03:14 -0300 (EST) From: Roberto Jung Drebes X-Sender: drebes@jacui To: devfs@oss.sgi.com Subject: devfsd and pam_console Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi there, Any plans to include support for pam_console (and /var/lock/console*, /etc/security/console*) in devfs, so that when a module was loaded (and consequently would register the devices at the device fs, it would chown it to the owner of the console as RH already does to the static devices? I understand this is not a perfect solution, but I believe it is a simple one. It would be even better if devfs supported ACLs and when the modules registered the devices, a ACL would be added allowing device access to the console owner to the device. Any plans of implementing POSIX ACLs in devfs? How would it be done? the ACL commands would be passed to devfsd that then would take proper action? TIA, -- Roberto Jung Drebes Porto Alegre, RS - Brasil http://www.inf.ufrgs.br/~drebes/ From owner-devfs@oss.sgi.com Mon Sep 3 21:32:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f844W2809780 for devfs-outgoing; Mon, 3 Sep 2001 21:32:02 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f844Vnd09771 for ; Mon, 3 Sep 2001 21:31:54 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f844Vih00688; Mon, 3 Sep 2001 22:31:44 -0600 Date: Mon, 3 Sep 2001 22:31:44 -0600 Message-Id: <200109040431.f844Vih00688@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Roberto Jung Drebes Cc: devfs@oss.sgi.com Subject: Re: devfsd and pam_console In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Roberto Jung Drebes writes: > Any plans to include support for pam_console (and > /var/lock/console*, /etc/security/console*) in devfs, so that when a > module was loaded (and consequently would register the devices at > the device fs, it would chown it to the owner of the console as RH > already does to the static devices? Let me get this straight: you want to set the ownership of some new device nodes created by a module, and that ownership is determined by who owns the console? You don't need to hack devfs to do this. All you need to do is configure devfsd appropriately. > I understand this is not a perfect solution, but I believe it is a > simple one. It would be even better if devfs supported ACLs and when > the modules registered the devices, a ACL would be added allowing > device access to the console owner to the device. This didn't parse well. You mean you want an ACL on the device which gives the console owner device rights? > Any plans of implementing POSIX ACLs in devfs? How would it be done? > the ACL commands would be passed to devfsd that then would take > proper action? Not at this stage. I'm waiting to see if we can get a ACL implementation accepted into the kernel. I don't want something devfs-specific. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Sep 4 06:51:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84DpPQ21004 for devfs-outgoing; Tue, 4 Sep 2001 06:51:25 -0700 Received: from inf.ufrgs.br (puma.inf.ufrgs.br [143.54.11.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84DpKd20999 for ; Tue, 4 Sep 2001 06:51:20 -0700 Received: from jacui (jacui [143.54.11.130]) by inf.ufrgs.br (8.11.0/8.11.3) with ESMTP id f84DmtA32569; Tue, 4 Sep 2001 10:48:55 -0300 Date: Tue, 4 Sep 2001 10:51:36 -0300 (EST) From: Roberto Jung Drebes X-Sender: drebes@jacui To: Richard Gooch cc: devfs@oss.sgi.com Subject: Re: devfsd and pam_console In-Reply-To: <200109040431.f844Vih00688@vindaloo.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, 3 Sep 2001, Richard Gooch wrote: > Roberto Jung Drebes writes: > > Any plans to include support for pam_console (and > > /var/lock/console*, /etc/security/console*) in devfs, so that when a > > module was loaded (and consequently would register the devices at > > the device fs, it would chown it to the owner of the console as RH > > already does to the static devices? > > Let me get this straight: you want to set the ownership of some new > device nodes created by a module, and that ownership is determined by > who owns the console? Exacltly. > You don't need to hack devfs to do this. All you need to do is > configure devfsd appropriately. How do I do that? Should I add a REGISTER line for every device that will look the device name in a configuration file (like console.perms) and chown it acordingly? > > I understand this is not a perfect solution, but I believe it is a > > simple one. It would be even better if devfs supported ACLs and when > > the modules registered the devices, a ACL would be added allowing > > device access to the console owner to the device. > > This didn't parse well. You mean you want an ACL on the device which > gives the console owner device rights? Yes. I think it would be better to just add an ACL with permissions to that user when he logs in and remove it when he logs out than really changing the ownership of the device (as it' s done currently on RH). > > Any plans of implementing POSIX ACLs in devfs? How would it be done? > > the ACL commands would be passed to devfsd that then would take > > proper action? > > Not at this stage. I'm waiting to see if we can get a ACL > implementation accepted into the kernel. I don't want something > devfs-specific. The XFS and ext2 ACL people are trying to agree in a library call interface. Wouldn't POSIX ACLs not be devfs-specific? -- Roberto Jung Drebes Porto Alegre, RS - Brasil http://www.inf.ufrgs.br/~drebes/ From owner-devfs@oss.sgi.com Tue Sep 4 07:47:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84ElB223134 for devfs-outgoing; Tue, 4 Sep 2001 07:47:11 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84El7d23131 for ; Tue, 4 Sep 2001 07:47:07 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f84El3504278; Tue, 4 Sep 2001 08:47:03 -0600 Date: Tue, 4 Sep 2001 08:47:03 -0600 Message-Id: <200109041447.f84El3504278@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Roberto Jung Drebes Cc: devfs@oss.sgi.com Subject: Re: devfsd and pam_console In-Reply-To: References: <200109040431.f844Vih00688@vindaloo.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Roberto Jung Drebes writes: > On Mon, 3 Sep 2001, Richard Gooch wrote: > > > Roberto Jung Drebes writes: > > > Any plans to include support for pam_console (and > > > /var/lock/console*, /etc/security/console*) in devfs, so that when a > > > module was loaded (and consequently would register the devices at > > > the device fs, it would chown it to the owner of the console as RH > > > already does to the static devices? > > > > Let me get this straight: you want to set the ownership of some new > > device nodes created by a module, and that ownership is determined by > > who owns the console? > > Exacltly. > > > You don't need to hack devfs to do this. All you need to do is > > configure devfsd appropriately. > > How do I do that? Should I add a REGISTER line for every device that > will look the device name in a configuration file (like > console.perms) and chown it acordingly? Yes. > > > I understand this is not a perfect solution, but I believe it is a > > > simple one. It would be even better if devfs supported ACLs and when > > > the modules registered the devices, a ACL would be added allowing > > > device access to the console owner to the device. > > > > This didn't parse well. You mean you want an ACL on the device which > > gives the console owner device rights? > > Yes. I think it would be better to just add an ACL with permissions to > that user when he logs in and remove it when he logs out than really > changing the ownership of the device (as it' s done currently on RH). > > > > Any plans of implementing POSIX ACLs in devfs? How would it be done? > > > the ACL commands would be passed to devfsd that then would take > > > proper action? > > > > Not at this stage. I'm waiting to see if we can get a ACL > > implementation accepted into the kernel. I don't want something > > devfs-specific. > > The XFS and ext2 ACL people are trying to agree in a library call > interface. Wouldn't POSIX ACLs not be devfs-specific? I would hope that POSIX ACL's are fine for devfs. So I'll wait to see what gets put into the kernel. I'm also hoping that there will be good VFS support for ACL's, because eventually I want to remove my own directory structure and just use the dcache. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Sep 4 08:18:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84FIO623966 for devfs-outgoing; Tue, 4 Sep 2001 08:18:24 -0700 Received: from vertex.london.excite.com (vertex.london.excite.com [194.216.238.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84FIKd23962 for ; Tue, 4 Sep 2001 08:18:20 -0700 Received: from dhcp-64.london.excite.com (lave.london.excite.com) [194.216.238.64] by vertex.london.excite.com with esmtp (Exim 3.22 #1 (Debian)) id 15eHxu-0006DK-00 for ; Tue, 04 Sep 2001 16:18:14 +0100 Received: from abowley by lave.london.excite.com with local (Exim 3.32 #1 (Debian)) id 15eIma-0000Ex-00 for ; Tue, 04 Sep 2001 17:10:36 +0100 Date: Tue, 4 Sep 2001 17:10:36 +0100 From: Alex Bowley To: devfs@oss.sgi.com Subject: ownership of target of /dev/cdroms/cdroms0 Message-ID: <20010904171036.B571@london.excite.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline User-Agent: Mutt/1.3.20i Organization: Excite UK Sender: owner-devfs@oss.sgi.com Precedence: bulk --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'm having problems configuring my cdrom drive to have the correct owne= rship under devfsd. On bootup, my cdrom is in the 'disk' group by default, vis: lave:/dev# ls -l cdrom cdroms/cdrom0 ide/host0/bus1/target0/lun0/cd=20 lr-xr-xr-x 1 root root 13 Sep 4 16:59 cdrom -> cdroms/cdr= om0 lr-xr-xr-x 1 root root 33 Jan 1 1970 cdroms/cdrom0 -> ..= /ide/host0/bus1/target0/lun0/cd brw-rw---- 1 root disk 22, 0 Jan 1 1970 ide/host0/bus1/targ= et0/lun0/cd If I then attempt to access the drive, for instance using cdplay, or alteri= ng permissions / ownership of the cdrom* symlinks, and _then_ restart devfs= d, then the ownership of /dev/ide/host0/bus1/target0/lun0/cd changes to 'ro= ot:cdrom', and I can read from the drive (as a normal user). If I add the following line to /etc/devfs/perms, then it fixes the problem; REGISTER ^hdc* PERMISSIONS root.cdrom 0660 I get the gut feeling that this is the Wrong Way to do this. Can anyone eit= her placate this or advise better ways? --=20 Alex Bowley, Production Engineer, Excite UK alex.bowley@excitehome= .net "This man has the mind of a four year old boy, and I bet he was glad to get= rid of it." - Groucho Marx --qcHopEYAB45HaUaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7lPz8WnjMvezxgiwRAkfbAKCybFXdtttkvKGdics+u885J5vgogCgkMRO RV8sJccE7BXpp+yx8x2j62U= =WTxw -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From owner-devfs@oss.sgi.com Tue Sep 4 08:37:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f84Fbfe24479 for devfs-outgoing; Tue, 4 Sep 2001 08:37:41 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f84Fbcd24476 for ; Tue, 4 Sep 2001 08:37:38 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f84Fbbu05192; Tue, 4 Sep 2001 09:37:37 -0600 Date: Tue, 4 Sep 2001 09:37:37 -0600 Message-Id: <200109041537.f84Fbbu05192@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Alex Bowley Cc: devfs@oss.sgi.com Subject: Re: ownership of target of /dev/cdroms/cdroms0 In-Reply-To: <20010904171036.B571@london.excite.com> References: <20010904171036.B571@london.excite.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Alex Bowley writes: > > --qcHopEYAB45HaUaB > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable Argh! Please fix your mailer to send plain ASCII, not this Son-of-MIME crap. > Hi. I'm having problems configuring my cdrom drive to have the correct owne= > rship under devfsd. > > On bootup, my cdrom is in the 'disk' group by default, vis: > lave:/dev# ls -l cdrom cdroms/cdrom0 ide/host0/bus1/target0/lun0/cd=20 > lr-xr-xr-x 1 root root 13 Sep 4 16:59 cdrom -> cdroms/cdr= > om0 > lr-xr-xr-x 1 root root 33 Jan 1 1970 cdroms/cdrom0 -> ..= > /ide/host0/bus1/target0/lun0/cd > brw-rw---- 1 root disk 22, 0 Jan 1 1970 ide/host0/bus1/targ= > et0/lun0/cd > > If I then attempt to access the drive, for instance using cdplay, or alteri= > ng permissions / ownership of the cdrom* symlinks, and _then_ restart devfs= > d, then the ownership of /dev/ide/host0/bus1/target0/lun0/cd changes to 'ro= > ot:cdrom', and I can read from the drive (as a normal user). > > If I add the following line to /etc/devfs/perms, then it fixes the problem; > REGISTER ^hdc* PERMISSIONS root.cdrom 0660 > > I get the gut feeling that this is the Wrong Way to do this. Can anyone eit= > her placate this or advise better ways? Sounds like you have a Debian system. What you're doing may or may not fit in with the Debian way of doing things. I'll let Russell Coker, who is the Debian package maintainer for devfsd, reply. I believe he is on this list. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Sep 5 13:34:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85KYer31286 for devfs-outgoing; Wed, 5 Sep 2001 13:34:40 -0700 Received: from ivanova.coker.com.au (postfix@ivanova.coker.com.au [203.36.46.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85KYVd31274 for ; Wed, 5 Sep 2001 13:34:34 -0700 Received: from lyta.coker.com.au (ivanova [127.0.0.1]) by ivanova.coker.com.au (Postfix) with ESMTP id AC32FFB7B; Thu, 6 Sep 2001 06:34:04 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id A428A34F1F; Wed, 5 Sep 2001 22:33:03 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Alex Bowley Subject: Re: ownership of target of /dev/cdroms/cdroms0 in devfs Date: Wed, 5 Sep 2001 22:18:21 +0200 X-Mailer: KMail [version 1.3.1] Cc: devfs@oss.sgi.com, debian-user@lists.debian.org References: <20010904171036.B571@london.excite.com> <200109041537.f84Fbbu05192@vindaloo.ras.ucalgary.ca> In-Reply-To: <200109041537.f84Fbbu05192@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Message-Id: <20010905203303.A428A34F1F@lyta.coker.com.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f85KYad31284 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 4 Sep 2001 17:37, Richard Gooch wrote: > > If I then attempt to access the drive, for instance using cdplay, or > > alteri= ng permissions / ownership of the cdrom* symlinks, and _then_ > > restart devfs= d, then the ownership of > > /dev/ide/host0/bus1/target0/lun0/cd changes to 'ro= ot:cdrom', and I can > > read from the drive (as a normal user). > > > > If I add the following line to /etc/devfs/perms, then it fixes the > > problem; REGISTER ^hdc* PERMISSIONS root.cdrom 0660 > > > > I get the gut feeling that this is the Wrong Way to do this. Can anyone > > eit= her placate this or advise better ways? > > Sounds like you have a Debian system. What you're doing may or may not > fit in with the Debian way of doing things. I'll let Russell Coker, > who is the Debian package maintainer for devfsd, reply. I believe he > is on this list. OK. The are two differences between the Debian package and the default devfsd installation in this regard. One is the /etc/devfs directory and the perms file that is included in the configuration which has default permissions. I recommend that you add things to /etc/devfs/conf.d/something instead of changing the perms file, then on Debian package upgrade if the default perms file has new devices added they will automatically appear in your configuration (and you will not be bothered by questions about whether you want to replace the file). The other change is more significant. The function make_symlink() in devfsd.c which is called for MKOLDCOMPAT (and presumably MKNEWCOMPAT and others) will check PERMISSIONS entries for a match on the sym-link name and chance the permissions of the link target as if it was the subject of the permissions line. The result of this is that many things "just work" without any effort. The down-side as you have probably noticed is that removing a MKOLDCOMPAT entry can have changes to the permissions that are unexpected. There are already some bug reports in the Debian BTS regarding default permissions of the IDE device files. I will have to decide what to do, maybe the following: REGISTER ^ide/host[0-9]+/bus[0-9]+/target[0-9]+/lun0/cd PERMISSIONS root.cdrom 640 I would not be about to give write access to a CD burner to anyone other than root by default... Also any permissions related configuration directives in /etc/devfs/conf.d/* will over-ride /etc/devfs/perms (so there's no real need to comment anything out of /etc/devfs/perms unless you are making permissions more restrictive and want to avoid race conditions). I have CC'd this to the debian-user list as I think that other Debian users will be interested in the discussion. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Wed Sep 5 15:18:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f85MIXv00535 for devfs-outgoing; Wed, 5 Sep 2001 15:18:33 -0700 Received: from atoka-software.com (IDENT:qmailr@[207.20.242.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f85MIRd00519 for ; Wed, 5 Sep 2001 15:18:27 -0700 Received: (qmail 30892 invoked by uid 0); 5 Sep 2001 22:13:13 -0000 MBOX-Line: From bounce-debian-user=debian=atoka-software.com@lists.debian.org Wed Sep 5 15:13:13 2001 Received: from shell5.ba.best.com [206.184.139.136] by localhost with POP3 (fetchmail-5.5.0) for awbesq+XRCPT.64656269616e4061746f6b612d736f6674776172652e636f6d@shell5.ba.best.com (multi-drop); Wed, 05 Sep 2001 15:13:12 -0700 (PDT) Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.13]) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id PAA19203 for ; Wed, 5 Sep 2001 15:04:33 -0700 (PDT) Received: from murphy.debian.org (murphy.debian.org [216.234.231.6]) by proxy3.ba.best.com (8.9.3/8.9.2/best.in) with SMTP id PAA19852 for ; Wed, 5 Sep 2001 15:03:44 -0700 (PDT) Received: (qmail 2279 invoked by uid 38); 5 Sep 2001 21:07:11 -0000 Received: (qmail 10714 invoked from network); 5 Sep 2001 21:02:00 -0000 Received: from master.debian.org (216.234.231.130) by murphy.debian.org with SMTP; 5 Sep 2001 21:02:00 -0000 Received: from ivanova.coker.com.au [203.36.46.209] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15ejSA-0007S3-00; Wed, 05 Sep 2001 15:39:19 -0500 Received: from lyta.coker.com.au (ivanova [127.0.0.1]) by ivanova.coker.com.au (Postfix) with ESMTP id AC32FFB7B; Thu, 6 Sep 2001 06:34:04 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id A428A34F1F; Wed, 5 Sep 2001 22:33:03 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Alex Bowley Subject: Re: ownership of target of /dev/cdroms/cdroms0 in devfs Date: Wed, 5 Sep 2001 22:18:21 +0200 X-Mailer: KMail [version 1.3.1] Cc: devfs@oss.sgi.com, debian-user@lists.debian.org References: <20010904171036.B571@london.excite.com> <200109041537.f84Fbbu05192@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Message-Id: <20010905203303.A428A34F1F@lyta.coker.com.au> Content-Transfer-Encoding: 8bit X-UIDL: bbaf82677c346da369ac3d8898d4acda Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 4 Sep 2001 17:37, Richard Gooch wrote: > > If I then attempt to access the drive, for instance using cdplay, or > > alteri= ng permissions / ownership of the cdrom* symlinks, and _then_ > > restart devfs= d, then the ownership of > > /dev/ide/host0/bus1/target0/lun0/cd changes to 'ro= ot:cdrom', and I can > > read from the drive (as a normal user). > > > > If I add the following line to /etc/devfs/perms, then it fixes the > > problem; REGISTER ^hdc* PERMISSIONS root.cdrom 0660 > > > > I get the gut feeling that this is the Wrong Way to do this. Can anyone > > eit= her placate this or advise better ways? > > Sounds like you have a Debian system. What you're doing may or may not > fit in with the Debian way of doing things. I'll let Russell Coker, > who is the Debian package maintainer for devfsd, reply. I believe he > is on this list. OK. The are two differences between the Debian package and the default devfsd installation in this regard. One is the /etc/devfs directory and the perms file that is included in the configuration which has default permissions. I recommend that you add things to /etc/devfs/conf.d/something instead of changing the perms file, then on Debian package upgrade if the default perms file has new devices added they will automatically appear in your configuration (and you will not be bothered by questions about whether you want to replace the file). The other change is more significant. The function make_symlink() in devfsd.c which is called for MKOLDCOMPAT (and presumably MKNEWCOMPAT and others) will check PERMISSIONS entries for a match on the sym-link name and chance the permissions of the link target as if it was the subject of the permissions line. The result of this is that many things "just work" without any effort. The down-side as you have probably noticed is that removing a MKOLDCOMPAT entry can have changes to the permissions that are unexpected. There are already some bug reports in the Debian BTS regarding default permissions of the IDE device files. I will have to decide what to do, maybe the following: REGISTER ^ide/host[0-9]+/bus[0-9]+/target[0-9]+/lun0/cd PERMISSIONS root.cdrom 640 I would not be about to give write access to a CD burner to anyone other than root by default... Also any permissions related configuration directives in /etc/devfs/conf.d/* will over-ride /etc/devfs/perms (so there's no real need to comment anything out of /etc/devfs/perms unless you are making permissions more restrictive and want to avoid race conditions). I have CC'd this to the debian-user list as I think that other Debian users will be interested in the discussion. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to debian-user-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org From owner-devfs@oss.sgi.com Fri Sep 7 15:00:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f87M0hR20456 for devfs-outgoing; Fri, 7 Sep 2001 15:00:43 -0700 Received: from web10907.mail.yahoo.com (web10907.mail.yahoo.com [216.136.131.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f87M0ed20450 for ; Fri, 7 Sep 2001 15:00:40 -0700 Message-ID: <20010907220040.35525.qmail@web10907.mail.yahoo.com> Received: from [63.79.238.123] by web10907.mail.yahoo.com via HTTP; Fri, 07 Sep 2001 15:00:40 PDT Date: Fri, 7 Sep 2001 15:00:40 -0700 (PDT) From: Brad Chapman Subject: [IDEA] Enhanced trace level system To: devfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Everyone, I just got an idea: why don't we implement a userspace trace level system for devfsd with macro'd levels like the following: /* Basic trace levels */ #define TRACE_LEVEL_ZERO 0 /* None */ #define TRACE_LEVEL_SPECIFIED 1 /* Specified on the command line */ #define TRACE_LEVEL_SIGNALS 2 /* Trapped and caught signals */ #define TRACE_LEVEL_PROCESS_FORK 3 /* Process forks for MODLOAD and EXECUTE */ #define TRACE_LEVEL_SERVICE_LOOP 4 /* devfs event service loops */ #define TRACE_LEVEL_CONFIG 5 /* devfsd configuration */ #define TRACE_LEVEL_KERNEL 6 /* Kernel-passed information */ /* Debugging trace levels */ #define TRACE_LEVEL_DEBUGGING 7 /* Basic debugging */ #define TRACE_LEVEL_KERNEL_DBG 8 /* Kernel-passed information debugging */ #define TRACE_LEVEL_CONFIG_DBG 9 /* Configuration debugging */ #define TRACE_LEVEL_COMPAT_NAME_DBG 10 /* Compatiblity name debugging */ #define TRACE_LEVEL_EXPRESSION_DBG 11 /* Regular expression debugging */ Does anyone think this is a good idea? Brad ===== Brad Chapman Permanent e-mail: kakadu_croc@yahoo.com Current e-mail: kakadu@adelphia.net Alternate e-mail: kakadu@netscape.net __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-devfs@oss.sgi.com Mon Sep 10 12:25:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8AJPgx25134 for devfs-outgoing; Mon, 10 Sep 2001 12:25:42 -0700 Received: from cicero.gsfc.nasa.gov (cicero.gsfc.nasa.gov [128.183.34.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8AJPbd25131 for ; Mon, 10 Sep 2001 12:25:37 -0700 Received: from gsfc.nasa.gov (cicero.gsfc.nasa.gov [128.183.34.42]) by cicero.gsfc.nasa.gov (8.9.3/8.9.3) with ESMTP id PAA18358 for ; Mon, 10 Sep 2001 15:25:37 -0400 Message-ID: <3B9D13B0.3A365737@gsfc.nasa.gov> Date: Mon, 10 Sep 2001 15:25:36 -0400 From: "Randall A. Jones" Organization: Scientific Visualization Studio X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.15-3SGI_39_2G i686) X-Accept-Language: en MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: missing /dev/systty, /dev/ram for mkinitrd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello. I am trying to install a new kernel. I need to create a new initrd image for booting from SCSI. first, loopback device files aren't present at boot until I manually do modprobe loop. then mkinitrd complains: -- mkinitrd -f --with=loop initrd-2.2.15-3SGI_39_2G.img 2.2.15-3SGI_39_2G cp: /dev/ram: No such file or directory cp: /dev/systty: No such file or directory -- mkinitrd must be looking for the old device files? system stats: kernel 2.2.15-3SGI_39 (sgi ProPack 1.3, VWE) mkinitrd: version 2.4.1 devfsd: Linux device filesystem daemon v1.3.8 In the old static /dev, /dev/systty is the same as /dev/tty0 /dev/ram is same as /dev/ram1 in the newest devfs /dev, tty0 is a link to vc/0 /dev/tty0 -> vc/0 /dev/ram1 -> rd/1 can I tell/configure devfs/devfsd to use (or add links) the old names without breaking current functionality. Thanks! Randy -- __________________________________________________________________ Scientific Visualization Studio _/_/_/_/ _| _/ _/_/_/_/ NASA Goddard Space Flight Center _/ _| _/ _/ Code 935 301-286-2239 _/_/_/_/ _| _/ _/_/_/_/ Randall A. Jones GST _/ _| _/ _/ Randall.A.Jones@gsfc.nasa.gov _/_/_/_/ _|_/ _/_/_/_/ http://svs.gsfc.nasa.gov __________________________________________________________________ From owner-devfs@oss.sgi.com Tue Sep 11 08:17:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BFHjT18650 for devfs-outgoing; Tue, 11 Sep 2001 08:17:45 -0700 Received: from ivanova.coker.com.au (postfix@ivanova.coker.com.au [203.36.46.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BFHed18644 for ; Tue, 11 Sep 2001 08:17:41 -0700 Received: from lyta.coker.com.au (ivanova [127.0.0.1]) by ivanova.coker.com.au (Postfix) with ESMTP id 5367BFB0F; Wed, 12 Sep 2001 01:17:35 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 7F7D9365088; Tue, 11 Sep 2001 17:17:06 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: "Randall A. Jones" , devfs@oss.sgi.com Subject: Re: missing /dev/systty, /dev/ram for mkinitrd Date: Tue, 11 Sep 2001 14:14:53 +0200 X-Mailer: KMail [version 1.3.1] References: <3B9D13B0.3A365737@gsfc.nasa.gov> In-Reply-To: <3B9D13B0.3A365737@gsfc.nasa.gov> MIME-Version: 1.0 Message-Id: <20010911151706.7F7D9365088@lyta.coker.com.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BFHgd18646 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, 10 Sep 2001 21:25, Randall A. Jones wrote: > I am trying to install a new kernel. I need to create a new initrd image > for booting from SCSI. > > first, loopback device files aren't present at boot until I manually do > modprobe loop. > then > mkinitrd complains: > > mkinitrd -f --with=loop initrd-2.2.15-3SGI_39_2G.img 2.2.15-3SGI_39_2G > cp: /dev/ram: No such file or directory > cp: /dev/systty: No such file or directory Configure your modutils with the following alias entries: /dev/ram rd /dev/loop loop Also make sure that you have MKOLDCOMPAT entries for the ram disk. As for systty, what is it anyway? It's not mentioned in linux/Documentation/devices.txt... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Tue Sep 11 08:17:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BFHpb18657 for devfs-outgoing; Tue, 11 Sep 2001 08:17:51 -0700 Received: from ivanova.coker.com.au (postfix@ivanova.coker.com.au [203.36.46.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BFHed18645 for ; Tue, 11 Sep 2001 08:17:41 -0700 Received: from lyta.coker.com.au (ivanova [127.0.0.1]) by ivanova.coker.com.au (Postfix) with ESMTP id 212D1FB0C; Wed, 12 Sep 2001 01:17:35 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id C1AB436508C; Tue, 11 Sep 2001 17:17:06 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: rgooch@ras.ucalgary.ca, lnz@dandelion.com Subject: DAC960 and ram disk devfs conflict Date: Tue, 11 Sep 2001 16:15:50 +0200 X-Mailer: KMail [version 1.3.1] Cc: devfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <20010911151706.C1AB436508C@lyta.coker.com.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8BFHgd18647 Sender: owner-devfs@oss.sgi.com Precedence: bulk Is there any resolution to the issue of /dev/rd being used for both RAM disks and Mylex RAID controllers? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Tue Sep 11 08:37:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8BFbHd19058 for devfs-outgoing; Tue, 11 Sep 2001 08:37:17 -0700 Received: from dandelion.com (IDENT:3ugW7Z+Fumk2P22gtJ0Zd/fovrqArD3U@dandelion.com [198.186.200.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8BFbGd19054 for ; Tue, 11 Sep 2001 08:37:16 -0700 Received: (from lnz@localhost) by dandelion.com (8.11.6/8.11.6) id f8BFb6r07147; Tue, 11 Sep 2001 08:37:06 -0700 Date: Tue, 11 Sep 2001 08:37:06 -0700 Message-Id: <200109111537.f8BFb6r07147@dandelion.com> From: "Leonard N. Zubkoff" To: russell@coker.com.au CC: rgooch@ras.ucalgary.ca, devfs@oss.sgi.com In-reply-to: <20010911151706.C1AB436508C@lyta.coker.com.au> (message from Russell Coker on Tue, 11 Sep 2001 16:15:50 +0200) Subject: Re: DAC960 and ram disk devfs conflict Sender: owner-devfs@oss.sgi.com Precedence: bulk From: Russell Coker Date: Tue, 11 Sep 2001 16:15:50 +0200 Is there any resolution to the issue of /dev/rd being used for both RAM disks and Mylex RAID controllers? Afraid not. Leonard From owner-devfs@oss.sgi.com Sun Sep 16 21:41:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8H4fld25869 for devfs-outgoing; Sun, 16 Sep 2001 21:41:47 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8H4ffe25861 for ; Sun, 16 Sep 2001 21:41:42 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f8GNruh08846; Sun, 16 Sep 2001 19:53:56 -0400 Date: Sun, 16 Sep 2001 19:53:56 -0400 Message-Id: <200109162353.f8GNruh08846@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Alex Bowley , devfs@oss.sgi.com, debian-user@lists.debian.org Subject: Re: ownership of target of /dev/cdroms/cdroms0 in devfs In-Reply-To: <20010905203303.A428A34F1F@lyta.coker.com.au> References: <20010904171036.B571@london.excite.com> <200109041537.f84Fbbu05192@vindaloo.ras.ucalgary.ca> <20010905203303.A428A34F1F@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: [...] > Also any permissions related configuration directives in > /etc/devfs/conf.d/* will over-ride /etc/devfs/perms (so there's no > real need to comment anything out of /etc/devfs/perms unless you are > making permissions more restrictive and want to avoid race > conditions). What race conditions are you referring to? Filesystem access to entries is blocked until devfsd has finished processing all pending events. So no process can ever see an intermediate state. Only devfsd and it's children can bypass this block. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Sep 16 21:41:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8H4fvq25899 for devfs-outgoing; Sun, 16 Sep 2001 21:41:57 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8H4fse25893 for ; Sun, 16 Sep 2001 21:41:54 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f8GNgg308823; Sun, 16 Sep 2001 19:42:42 -0400 Date: Sun, 16 Sep 2001 19:42:42 -0400 Message-Id: <200109162342.f8GNgg308823@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Brad Chapman Cc: devfs@oss.sgi.com Subject: Re: [IDEA] Enhanced trace level system In-Reply-To: <20010907220040.35525.qmail@web10907.mail.yahoo.com> References: <20010907220040.35525.qmail@web10907.mail.yahoo.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Brad Chapman writes: > I just got an idea: why don't we implement a userspace trace level > system for devfsd with macro'd levels like the following: > > /* Basic trace levels */ > #define TRACE_LEVEL_ZERO 0 /* None */ > #define TRACE_LEVEL_SPECIFIED 1 /* Specified on the command line */ > #define TRACE_LEVEL_SIGNALS 2 /* Trapped and caught signals */ > #define TRACE_LEVEL_PROCESS_FORK 3 /* Process forks for MODLOAD and EXECUTE */ > #define TRACE_LEVEL_SERVICE_LOOP 4 /* devfs event service loops */ > #define TRACE_LEVEL_CONFIG 5 /* devfsd configuration */ > #define TRACE_LEVEL_KERNEL 6 /* Kernel-passed information */ > > /* Debugging trace levels */ > #define TRACE_LEVEL_DEBUGGING 7 /* Basic debugging */ > #define TRACE_LEVEL_KERNEL_DBG 8 /* Kernel-passed information debugging */ > #define TRACE_LEVEL_CONFIG_DBG 9 /* Configuration debugging */ > #define TRACE_LEVEL_COMPAT_NAME_DBG 10 /* Compatiblity name debugging */ > #define TRACE_LEVEL_EXPRESSION_DBG 11 /* Regular expression debugging */ > > Does anyone think this is a good idea? It's not clear to me what some of these trace levels are, nor what is to be done with them. What is it you are trying to do, anyway? Also note that I'm not keen on adding code to the core of devfsd unless necessary. So I'd look more favourably on an extension. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun Sep 16 21:48:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8H4m4726031 for devfs-outgoing; Sun, 16 Sep 2001 21:48:04 -0700 Received: from atoka-software.com (IDENT:qmailr@[207.20.242.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8H4m1e26028 for ; Sun, 16 Sep 2001 21:48:01 -0700 Received: (qmail 2974 invoked by uid 0); 17 Sep 2001 04:42:17 -0000 MBOX-Line: From bounce-debian-user=debian=atoka-software.com@lists.debian.org Sun Sep 16 21:42:17 2001 Received: from shell5.ba.best.com [206.184.139.136] by localhost with POP3 (fetchmail-5.5.0) for awbesq+XRCPT.64656269616e4061746f6b612d736f6674776172652e636f6d@shell5.ba.best.com (multi-drop); Sun, 16 Sep 2001 21:41:45 -0700 (PDT) Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id VAA21201 for ; Sun, 16 Sep 2001 21:43:55 -0700 (PDT) Received: from murphy.debian.org (murphy.debian.org [216.234.231.6]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with SMTP id VAA19636 for ; Sun, 16 Sep 2001 21:42:25 -0700 (PDT) Received: (qmail 11514 invoked by uid 38); 17 Sep 2001 04:41:38 -0000 Received: (qmail 11480 invoked from network); 17 Sep 2001 04:41:37 -0000 Received: from h-207-228-73-44.gen.cadvision.com (HELO mobilix.ras.ucalgary.ca) (207.228.73.44) by murphy.debian.org with SMTP; 17 Sep 2001 04:41:37 -0000 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f8GNruh08846; Sun, 16 Sep 2001 19:53:56 -0400 Date: Sun, 16 Sep 2001 19:53:56 -0400 Message-Id: <200109162353.f8GNruh08846@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Alex Bowley , devfs@oss.sgi.com, debian-user@lists.debian.org Subject: Re: ownership of target of /dev/cdroms/cdroms0 in devfs References: <20010904171036.B571@london.excite.com> <200109041537.f84Fbbu05192@vindaloo.ras.ucalgary.ca> <20010905203303.A428A34F1F@lyta.coker.com.au> X-UIDL: 99a8816def0e413c898c2160aeb07663 Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: [...] > Also any permissions related configuration directives in > /etc/devfs/conf.d/* will over-ride /etc/devfs/perms (so there's no > real need to comment anything out of /etc/devfs/perms unless you are > making permissions more restrictive and want to avoid race > conditions). What race conditions are you referring to? Filesystem access to entries is blocked until devfsd has finished processing all pending events. So no process can ever see an intermediate state. Only devfsd and it's children can bypass this block. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca -- To UNSUBSCRIBE, email to debian-user-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org From owner-devfs@oss.sgi.com Mon Sep 17 04:19:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8HBJfV01542 for devfs-outgoing; Mon, 17 Sep 2001 04:19:41 -0700 Received: from web10903.mail.yahoo.com (web10903.mail.yahoo.com [216.136.131.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8HBJXe01538 for ; Mon, 17 Sep 2001 04:19:33 -0700 Message-ID: <20010917111933.37053.qmail@web10903.mail.yahoo.com> Received: from [65.196.167.173] by web10903.mail.yahoo.com via HTTP; Mon, 17 Sep 2001 04:19:33 PDT Date: Mon, 17 Sep 2001 04:19:33 -0700 (PDT) From: Brad Chapman Subject: Re: [IDEA] Enhanced trace level system To: Richard Gooch Cc: devfs@oss.sgi.com In-Reply-To: <200109162342.f8GNgg308823@mobilix.ras.ucalgary.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-devfs@oss.sgi.com Precedence: bulk Mr. Gooch, --- Richard Gooch wrote: > Brad Chapman writes: > > I just got an idea: why don't we implement a userspace trace level > > system for devfsd with macro'd levels like the following: > > > > /* Basic trace levels */ > > #define TRACE_LEVEL_ZERO 0 /* None */ > > #define TRACE_LEVEL_SPECIFIED 1 /* Specified on the command line */ > > #define TRACE_LEVEL_SIGNALS 2 /* Trapped and caught signals */ > > #define TRACE_LEVEL_PROCESS_FORK 3 /* Process forks for MODLOAD and EXECUTE */ > > #define TRACE_LEVEL_SERVICE_LOOP 4 /* devfs event service loops */ > > #define TRACE_LEVEL_CONFIG 5 /* devfsd configuration */ > > #define TRACE_LEVEL_KERNEL 6 /* Kernel-passed information */ > > > > /* Debugging trace levels */ > > #define TRACE_LEVEL_DEBUGGING 7 /* Basic debugging */ > > #define TRACE_LEVEL_KERNEL_DBG 8 /* Kernel-passed information debugging */ > > #define TRACE_LEVEL_CONFIG_DBG 9 /* Configuration debugging */ > > #define TRACE_LEVEL_COMPAT_NAME_DBG 10 /* Compatiblity name debugging */ > > #define TRACE_LEVEL_EXPRESSION_DBG 11 /* Regular expression debugging */ > > > > Does anyone think this is a good idea? > > It's not clear to me what some of these trace levels are, nor what is > to be done with them. What is it you are trying to do, anyway? I'm trying to create a sort of tracing system where you can specify a mask on the command line (or a simple integer) and get a vareity of traced information about what devfsd is doing. The stuff I printed above was just an example of an incremental trace level system. > > Also note that I'm not keen on adding code to the core of devfsd > unless necessary. So I'd look more favourably on an extension. Extension? What sort of extension? How would you extend devfsd's tracing subsystem without actually modifying the core code? IDGT..... > > Regards, > > Richard.... > Permanent: rgooch@atnf.csiro.au > Current: rgooch@ras.ucalgary.ca Brad ===== Brad Chapman Permanent e-mail: kakadu_croc@yahoo.com Current e-mail: kakadu@adelphia.net Alternate e-mail: kakadu@netscape.net __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From owner-devfs@oss.sgi.com Mon Sep 17 13:24:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8HKOQJ12236 for devfs-outgoing; Mon, 17 Sep 2001 13:24:26 -0700 Received: from ivanova.coker.com.au (postfix@ivanova.coker.com.au [203.36.46.209]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8HKOLe12232 for ; Mon, 17 Sep 2001 13:24:22 -0700 Received: from lyta.coker.com.au (ivanova [127.0.0.1]) by ivanova.coker.com.au (Postfix) with ESMTP id 42930FAA8; Tue, 18 Sep 2001 06:24:10 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 8D3BC365BC5; Mon, 17 Sep 2001 22:22:23 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: ownership of target of /dev/cdroms/cdroms0 in devfs Date: Mon, 17 Sep 2001 18:35:00 +0200 X-Mailer: KMail [version 1.3.1] Cc: Alex Bowley , devfs@oss.sgi.com, debian-user@lists.debian.org References: <20010904171036.B571@london.excite.com> <20010905203303.A428A34F1F@lyta.coker.com.au> <200109162353.f8GNruh08846@mobilix.ras.ucalgary.ca> In-Reply-To: <200109162353.f8GNruh08846@mobilix.ras.ucalgary.ca> MIME-Version: 1.0 Message-Id: <20010917202223.8D3BC365BC5@lyta.coker.com.au> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f8HKONe12233 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, 17 Sep 2001 01:53, Richard Gooch wrote: > > Also any permissions related configuration directives in > > /etc/devfs/conf.d/* will over-ride /etc/devfs/perms (so there's no > > real need to comment anything out of /etc/devfs/perms unless you are > > making permissions more restrictive and want to avoid race > > conditions). > > What race conditions are you referring to? Filesystem access to > entries is blocked until devfsd has finished processing all pending > events. So no process can ever see an intermediate state. Only devfsd > and it's children can bypass this block. OK. Sorry I wasn't thinking when I wrote the message, I should have known that! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page From owner-devfs@oss.sgi.com Mon Sep 17 14:19:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8HLJKO13345 for devfs-outgoing; Mon, 17 Sep 2001 14:19:20 -0700 Received: from atoka-software.com (IDENT:qmailr@[207.20.242.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8HLJFe13339 for ; Mon, 17 Sep 2001 14:19:17 -0700 Received: (qmail 11242 invoked by uid 0); 17 Sep 2001 21:13:28 -0000 MBOX-Line: From bounce-debian-user=debian=atoka-software.com@lists.debian.org Mon Sep 17 14:13:28 2001 Received: from shell5.ba.best.com [206.184.139.136] by localhost with POP3 (fetchmail-5.5.0) for awbesq+XRCPT.64656269616e4061746f6b612d736f6674776172652e636f6d@shell5.ba.best.com (multi-drop); Mon, 17 Sep 2001 14:13:07 -0700 (PDT) Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.13]) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id OAA12192 for ; Mon, 17 Sep 2001 14:09:30 -0700 (PDT) Received: from murphy.debian.org (murphy.debian.org [216.234.231.6]) by proxy3.ba.best.com (8.9.3/8.9.2/best.in) with SMTP id OAA22452 for ; Mon, 17 Sep 2001 14:08:15 -0700 (PDT) Received: (qmail 31599 invoked by uid 38); 17 Sep 2001 20:48:59 -0000 Received: (qmail 27838 invoked from network); 17 Sep 2001 20:47:20 -0000 Received: from master.debian.org (mail@216.234.231.130) by murphy.debian.org with SMTP; 17 Sep 2001 20:47:20 -0000 Received: from ivanova.coker.com.au [203.36.46.209] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15j519-0001Ep-00; Mon, 17 Sep 2001 15:29:24 -0500 Received: from lyta.coker.com.au (ivanova [127.0.0.1]) by ivanova.coker.com.au (Postfix) with ESMTP id 42930FAA8; Tue, 18 Sep 2001 06:24:10 +1000 (EST) Received: from there (lyta [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 8D3BC365BC5; Mon, 17 Sep 2001 22:22:23 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: ownership of target of /dev/cdroms/cdroms0 in devfs Date: Mon, 17 Sep 2001 18:35:00 +0200 X-Mailer: KMail [version 1.3.1] Cc: Alex Bowley , devfs@oss.sgi.com, debian-user@lists.debian.org References: <20010904171036.B571@london.excite.com> <20010905203303.A428A34F1F@lyta.coker.com.au> <200109162353.f8GNruh08846@mobilix.ras.ucalgary.ca> MIME-Version: 1.0 Message-Id: <20010917202223.8D3BC365BC5@lyta.coker.com.au> Content-Transfer-Encoding: 8bit X-UIDL: 14fa217c044558925f91972eb9739aa5 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, 17 Sep 2001 01:53, Richard Gooch wrote: > > Also any permissions related configuration directives in > > /etc/devfs/conf.d/* will over-ride /etc/devfs/perms (so there's no > > real need to comment anything out of /etc/devfs/perms unless you are > > making permissions more restrictive and want to avoid race > > conditions). > > What race conditions are you referring to? Filesystem access to > entries is blocked until devfsd has finished processing all pending > events. So no process can ever see an intermediate state. Only devfsd > and it's children can bypass this block. OK. Sorry I wasn't thinking when I wrote the message, I should have known that! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to debian-user-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org From owner-devfs@oss.sgi.com Thu Sep 20 07:02:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KE2VX23582 for devfs-outgoing; Thu, 20 Sep 2001 07:02:31 -0700 Received: from tenshu.black-sun.co.uk (daimyo.gotadsl.co.uk [195.149.46.61]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KE2Pe23578 for ; Thu, 20 Sep 2001 07:02:25 -0700 Received: from cmsj by tenshu.black-sun.co.uk with local (Exim 3.22 #1 (Red Hat)) id 15k4PI-0004LY-00 for ; Thu, 20 Sep 2001 15:02:24 +0100 Date: Thu, 20 Sep 2001 15:02:24 +0100 From: Chris Jones To: devfs@oss.sgi.com Subject: Questions Message-ID: <20010920150224.B16480@tenshu.black-sun.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Uptime: 2:57pm up 7 days, 17:27, 4 users, load average: 1.00, 1.01, 0.94 Sender: owner-devfs@oss.sgi.com Precedence: bulk --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi I'm having a couple of problems with devfs: 1) When I shut my machine down (Red Hat 7.1 with 2.4.9 kernel) it complains that /dev is busy and can't be unmounted. I assume this is because things like init still have some stuff from /dev still mounted. Is it ok for /dev to still be mounted when the machine reboots? 2) I'm pretty sure I've configured devfs to correctly handle ownership/permissions across reboots by use of /var/state/devfs, I can chmod/chown something in /dev and the /var/state/devfs equivalent is updated to have the correct details, but when I reboot the permissions change quite a lot, with a number of devices (e.g. v4l ones) having ownership cmsj.root (cmsj being my user). There is definitely nothing in any of the boot scripts changing these permissions. Attached is my devfsd.conf, is there anything else I should send to help track this down? (I'm using RedHat's devfsd 2.4.3-12 RPM) Cheers, -- Chris "Ng" Jones chris@black-sun.co.uk www.linuxdude.co.uk --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="devfsd.conf" # Sample /etc/devfsd.conf configuration file. # Richard Gooch 3-JUL-2000 # # Enable full compatibility mode for old device names. You may comment these # out if you don't use the old device names. Make sure you know what you're # doing! REGISTER .* MKOLDCOMPAT UNREGISTER .* RMOLDCOMPAT # You may comment out the above and uncomment the following if you've # configured your system to use the original "new" devfs names or the really # new names #REGISTER vc/.* MKOLDCOMPAT #UNREGISTER vc/.* RMOLDCOMPAT #REGISTER pty/.* MKOLDCOMPAT #UNREGISTER pty/.* RMOLDCOMPAT #REGISTER misc MKOLDCOMPAT #UNREGISTER misc RMOLDCOMPAT # You may comment these out if you don't use the original "new" names REGISTER .* MKNEWCOMPAT UNREGISTER .* RMNEWCOMPAT # Personalised settings REGISTER ^v4l/video0$ CFUNCTION GLOBAL symlink v4l/video0 video REGISTER ^v4l/vbi0$ CFUNCTION GLOBAL symlink v4l/vbi0 vbi REGISTER ^st0$ CFUNCTION GLOBAL symlink st0 tape LOOKUP usb/rio500 EXECUTE /bin/mknod /dev/usb/rio500 c 180 64 # Enable module autoloading. You may comment this out if you don't use # autoloading LOOKUP .* MODLOAD # # Uncomment this if you want permissions to be saved and restored REGISTER ^pt[sy]/.* IGNORE CHANGE ^pt[sy]/.* IGNORE REGISTER .* COPY /var/state/devfs/$devname $devpath CHANGE .* COPY $devpath /var/state/devfs/$devname CREATE .* COPY $devpath /var/state/devfs/$devname --h31gzZEtNLTqOjlF-- From owner-devfs@oss.sgi.com Thu Sep 20 07:24:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KEOpd24105 for devfs-outgoing; Thu, 20 Sep 2001 07:24:51 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KEOle24102 for ; Thu, 20 Sep 2001 07:24:47 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8KEPot01787; Thu, 20 Sep 2001 08:25:50 -0600 Date: Thu, 20 Sep 2001 08:25:50 -0600 Message-Id: <200109201425.f8KEPot01787@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Chris Jones Cc: devfs@oss.sgi.com Subject: Re: Questions In-Reply-To: <20010920150224.B16480@tenshu.black-sun.co.uk> References: <20010920150224.B16480@tenshu.black-sun.co.uk> Sender: owner-devfs@oss.sgi.com Precedence: bulk Chris Jones writes: > I'm having a couple of problems with devfs: > > 1) When I shut my machine down (Red Hat 7.1 with 2.4.9 kernel) it > complains that /dev is busy and can't be unmounted. I assume this is > because things like init still have some stuff from /dev still mounted. > Is it ok for /dev to still be mounted when the machine reboots? Yep. Doesn't matter. If you grab a recent util-linux, you'll find that that annoying error message will go away. At least, I think I sent Andries a patch for that... > 2) I'm pretty sure I've configured devfs to correctly handle > ownership/permissions across reboots by use of /var/state/devfs, I > can chmod/chown something in /dev and the /var/state/devfs > equivalent is updated to have the correct details, but when I reboot > the permissions change quite a lot, with a number of devices > (e.g. v4l ones) having ownership cmsj.root (cmsj being my > user). There is definitely nothing in any of the boot scripts > changing these permissions. It's not clear what the problem is. Sure, when you reboot, the default permissions will change. Is something being change that you think shouldn't? Or is something not being changed that you think should? > Attached is my devfsd.conf, is there anything else I should send to help > track this down? > > # Uncomment this if you want permissions to be saved and restored > REGISTER ^pt[sy]/.* IGNORE > CHANGE ^pt[sy]/.* IGNORE > REGISTER .* COPY /var/state/devfs/$devname $devpath > CHANGE .* COPY $devpath /var/state/devfs/$devname > CREATE .* COPY $devpath /var/state/devfs/$devname Looks reasonable to me. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Sep 20 07:43:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KEhkZ24592 for devfs-outgoing; Thu, 20 Sep 2001 07:43:46 -0700 Received: from tenshu.black-sun.co.uk (daimyo.gotadsl.co.uk [195.149.46.61]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KEhee24582 for ; Thu, 20 Sep 2001 07:43:40 -0700 Received: from cmsj by tenshu.black-sun.co.uk with local (Exim 3.22 #1 (Red Hat)) id 15k535-0004Pd-00; Thu, 20 Sep 2001 15:43:31 +0100 Date: Thu, 20 Sep 2001 15:43:31 +0100 From: Chris Jones To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: Questions Message-ID: <20010920154331.A16769@tenshu.black-sun.co.uk> Mail-Followup-To: Richard Gooch , devfs@oss.sgi.com References: <20010920150224.B16480@tenshu.black-sun.co.uk> <200109201425.f8KEPot01787@vindaloo.ras.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109201425.f8KEPot01787@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Thu, Sep 20, 2001 at 08:25:50 -0600 X-Uptime: 3:29pm up 7 days, 17:59, 5 users, load average: 1.00, 0.94, 0.90 Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi * Richard Gooch (rgooch@ras.ucalgary.ca) wrote: > Yep. Doesn't matter. If you grab a recent util-linux, you'll find that > that annoying error message will go away. At least, I think I sent Excellent, thanks for clearing that up. > It's not clear what the problem is. Sure, when you reboot, the default > permissions will change. Is something being change that you think > shouldn't? > Or is something not being changed that you think should? It's kind of both, as my machine is now, /dev/v4l/video0 is owned cmsj.root with 600 permissions. I want to change this so it's owned root.core (core is a group I created) with 660 permissions: (this is going to look very wrong when its wrapped) # ls -l /dev/v4l/radio0 crw------- 1 cmsj root 81, 64 Jan 1 1970 /dev/v4l/radio0 # ls -l /var/state/devfs/v4l/radio0 crw------- 1 cmsj root 81, 64 Mar 4 2001 /var/state/devfs/v4l/radio0 # chown root.core /dev/v4l/radio0 # chmod 660 /dev/v4l/radio0 # ls -l /var/state/devfs/v4l/radio0 crw-rw---- 1 root core 81, 64 Mar 4 2001 /var/state/devfs/v4l/radio0 # ls -l /dev/v4l/radio0 crw-rw---- 1 root core 81, 64 Jan 1 1970 /dev/v4l/radio0 At this point everything seems to be ok, but if I reboot, /dev/v4l/radio0 will come back as cmsj.root and have 600 permissions. I really can't figure out why it keeps coming back owned by cmsj.root, I did have it owned that way at one point as an easy way of getting permissions to the device. I've scoured every inch of my bootup scripts and I'm positive that it isn't being manually forced to cmsj.root ownership: # grep -r cmsj /etc/rc.d/ # I've also checked to make sure that it isn't something in any .bashrc's or .profiles and there doesn't seem to be anything there that could cause it. The only thing I can think of that could possibly explain it is that the devfs /dev is being mounted on top of the real /dev (ie the one on the ext2 filesystem) and the on-disk /dev/v4l/radio0 is owned cmsj.root, but I don't then understand how that could propogate to /var/state/devfs because after a reboot the permissions/ownership are wrong there too. Thanks for your help, -- Chris "Ng" Jones chris@black-sun.co.uk www.linuxdude.co.uk From owner-devfs@oss.sgi.com Thu Sep 20 07:59:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KExUr25185 for devfs-outgoing; Thu, 20 Sep 2001 07:59:30 -0700 Received: from tenshu.black-sun.co.uk (daimyo.gotadsl.co.uk [195.149.46.61]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KExRe25181 for ; Thu, 20 Sep 2001 07:59:27 -0700 Received: from cmsj by tenshu.black-sun.co.uk with local (Exim 3.22 #1 (Red Hat)) id 15k5IQ-0004Tm-00; Thu, 20 Sep 2001 15:59:22 +0100 Date: Thu, 20 Sep 2001 15:59:22 +0100 From: Chris Jones To: Richard Gooch Cc: devfs@oss.sgi.com Subject: Re: Questions Message-ID: <20010920155922.A17076@tenshu.black-sun.co.uk> Mail-Followup-To: Richard Gooch , devfs@oss.sgi.com References: <20010920150224.B16480@tenshu.black-sun.co.uk> <200109201425.f8KEPot01787@vindaloo.ras.ucalgary.ca> <20010920154331.A16769@tenshu.black-sun.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010920154331.A16769@tenshu.black-sun.co.uk>; from chris@black-sun.co.uk on Thu, Sep 20, 2001 at 03:43:31 +0100 X-Uptime: 3:57pm up 7 days, 18:27, 5 users, load average: 0.94, 0.98, 0.96 Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi * Chris Jones (chris@black-sun.co.uk) wrote: > The only thing I can think of that could possibly explain it is that the > devfs /dev is being mounted on top of the real /dev (ie the one on the > ext2 filesystem) and the on-disk /dev/v4l/radio0 is owned cmsj.root, but I've just had a little poke around eith debug2fs and the first thing I noticed (and I should have figured this) is that there is no /dev/v4l, but there is a /dev/radio0 and it is indeed owned cmsj.root with permissions of 600: debugfs: stat dev/radio0 Inode: 180887 Type: character special Mode: 0600 Flags: 0x0 Generation: 3006163342 User: 500 Group: 0 Size: 0 (500 is the uid for cmsj) I just don't quite figure how this could be affecting devfs! -- Chris "Ng" Jones chris@black-sun.co.uk www.linuxdude.co.uk From owner-devfs@oss.sgi.com Thu Sep 20 08:03:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KF3Tp25387 for devfs-outgoing; Thu, 20 Sep 2001 08:03:29 -0700 Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KF3Re25381 for ; Thu, 20 Sep 2001 08:03:27 -0700 Received: from nce2.hadiko.de (hadince2.hadiko.uni-karlsruhe.de [172.20.32.2]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 15k5MK-0002JS-00; Thu, 20 Sep 2001 17:03:24 +0200 Received: from panorama.hadiko.de (hadii309.hadiko.uni-karlsruhe.de [172.20.44.69]) by nce2.hadiko.de (8.9.3/8.9.3) with SMTP id RAA06203 for ; Thu, 20 Sep 2001 17:03:22 +0200 (MET DST) Received: (qmail 12288 invoked from network); 20 Sep 2001 15:03:21 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Sep 2001 15:03:21 -0000 To: devfs@oss.sgi.com Subject: Default: unsecure From: Robert Siemer X-Mailer: Mew version 1.94b25 on Emacs 20.5 / Mule 4.0 (HANANOEN) Reply-To: Robert Siemer Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010920170320N.siemer@panorama.hadiko.de> Date: Thu, 20 Sep 2001 17:03:20 +0200 X-Dispatcher: imput version 990425(IM115) Lines: 14 Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi! Is there any reason to let the default permissions so unrestictive?? E.g. line printer and scsi tape are world read-/writeable by default! Here you need to change them anyway, so it would be very reasonable to start with root.root 600. Okay, it's not the fault of devfs core, but why are drivers registering their nodes this way? Regards, Robert From owner-devfs@oss.sgi.com Thu Sep 20 08:08:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KF8oM25473 for devfs-outgoing; Thu, 20 Sep 2001 08:08:50 -0700 Received: from mailgate.rz.uni-karlsruhe.de (mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KF8me25470 for ; Thu, 20 Sep 2001 08:08:48 -0700 Received: from nce2.hadiko.de (hadince2.hadiko.uni-karlsruhe.de [172.20.32.2]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 15k5RO-0002cv-00; Thu, 20 Sep 2001 17:08:42 +0200 Received: from panorama.hadiko.de (hadii309.hadiko.uni-karlsruhe.de [172.20.44.69]) by nce2.hadiko.de (8.9.3/8.9.3) with SMTP id RAA06319 for ; Thu, 20 Sep 2001 17:08:37 +0200 (MET DST) Received: (qmail 12385 invoked from network); 20 Sep 2001 15:08:35 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Sep 2001 15:08:35 -0000 To: chris@black-sun.co.uk Cc: devfs@oss.sgi.com Subject: Re: Questions From: Robert Siemer In-Reply-To: <20010920150224.B16480@tenshu.black-sun.co.uk> References: <20010920150224.B16480@tenshu.black-sun.co.uk> X-Mailer: Mew version 1.94b25 on Emacs 20.5 / Mule 4.0 (HANANOEN) Reply-To: Robert Siemer Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010920170834U.siemer@panorama.hadiko.de> Date: Thu, 20 Sep 2001 17:08:34 +0200 X-Dispatcher: imput version 990425(IM115) Lines: 11 Sender: owner-devfs@oss.sgi.com Precedence: bulk From: Chris Jones > ...but when I reboot the permissions > change quite a lot, with a number of devices (e.g. v4l ones) having > ownership cmsj.root (cmsj being my user). Look out for pam_console and files like console.perms in /etc/secu*. Regards, Robert From owner-devfs@oss.sgi.com Thu Sep 20 08:30:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KFUgU26151 for devfs-outgoing; Thu, 20 Sep 2001 08:30:42 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KFUde26145 for ; Thu, 20 Sep 2001 08:30:39 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8KFVbP02796; Thu, 20 Sep 2001 09:31:37 -0600 Date: Thu, 20 Sep 2001 09:31:37 -0600 Message-Id: <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Robert Siemer Cc: devfs@oss.sgi.com Subject: Re: Default: unsecure In-Reply-To: <20010920170320N.siemer@panorama.hadiko.de> References: <20010920170320N.siemer@panorama.hadiko.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk Robert Siemer writes: > Is there any reason to let the default permissions so unrestictive?? > E.g. line printer and scsi tape are world read-/writeable by default! Of course. Convenience. > Here you need to change them anyway, so it would be very reasonable > to start with root.root 600. What do you mean "here you need to change them anyway"? > Okay, it's not the fault of devfs core, but why are drivers > registering their nodes this way? Convenience. Is there a real problem with the relaxed default? On most Unix systems I've used, the tape devices are rw-rw-rw-. The sysadmin does not want to be bothered by user requests "can you please give me access to the tape drive so I can back up my data?". Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Sep 20 08:31:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KFV2o26183 for devfs-outgoing; Thu, 20 Sep 2001 08:31:02 -0700 Received: from tenshu.black-sun.co.uk (daimyo.gotadsl.co.uk [195.149.46.61]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KFV0e26180 for ; Thu, 20 Sep 2001 08:31:00 -0700 Received: from cmsj by tenshu.black-sun.co.uk with local (Exim 3.22 #1 (Red Hat)) id 15k5n0-0004XG-00; Thu, 20 Sep 2001 16:30:58 +0100 Date: Thu, 20 Sep 2001 16:30:58 +0100 From: Chris Jones To: Robert Siemer Cc: devfs@oss.sgi.com Subject: Re: Questions Message-ID: <20010920163058.A17263@tenshu.black-sun.co.uk> Mail-Followup-To: Robert Siemer , devfs@oss.sgi.com References: <20010920150224.B16480@tenshu.black-sun.co.uk> <20010920170834U.siemer@panorama.hadiko.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010920170834U.siemer@panorama.hadiko.de>; from Robert.Siemer@gmx.de on Thu, Sep 20, 2001 at 05:08:34 +0200 X-Uptime: 4:28pm up 7 days, 18:59, 5 users, load average: 1.00, 1.00, 0.96 Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi * Robert Siemer (Robert.Siemer@gmx.de) wrote: > Look out for pam_console and files like console.perms in /etc/secu*. I guess that could explain it. When I get home from work I'll reboot the box and check how the permissions/ownerships are arranged at different stages of booted-ness. I am assuming that if I tell lilo to use /bin/sh instead of init the PAM stuff won't be at all involved so I can try and rule that out as a possibility. -- Chris "Ng" Jones chris@black-sun.co.uk www.linuxdude.co.uk From owner-devfs@oss.sgi.com Thu Sep 20 09:47:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KGlSI28228 for devfs-outgoing; Thu, 20 Sep 2001 09:47:28 -0700 Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KGlKe28225 for ; Thu, 20 Sep 2001 09:47:21 -0700 Received: from nce2.hadiko.de (hadince2.hadiko.uni-karlsruhe.de [172.20.32.2]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 15k6ys-0001L8-00; Thu, 20 Sep 2001 18:47:18 +0200 Received: from panorama.hadiko.de (hadii309.hadiko.uni-karlsruhe.de [172.20.44.69]) by nce2.hadiko.de (8.9.3/8.9.3) with SMTP id SAA08769 for ; Thu, 20 Sep 2001 18:47:17 +0200 (MET DST) Received: (qmail 13100 invoked from network); 20 Sep 2001 16:47:16 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Sep 2001 16:47:16 -0000 To: devfs@oss.sgi.com Subject: Re: Default: unsecure From: Robert Siemer In-Reply-To: <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> References: <20010920170320N.siemer@panorama.hadiko.de> <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> X-Mailer: Mew version 1.94b25 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010920184715A.siemer@panorama.hadiko.de> Date: Thu, 20 Sep 2001 18:47:15 +0200 X-Dispatcher: imput version 990425(IM115) Lines: 68 Sender: owner-devfs@oss.sgi.com Precedence: bulk From: Richard Gooch > Robert Siemer writes: > > Is there any reason to let the default permissions so unrestictive?? > > E.g. line printer and scsi tape are world read-/writeable by default! > > Of course. Convenience. > > > Here you need to change them anyway, so it would be very reasonable > > to start with root.root 600. > > What do you mean "here you need to change them anyway"? Okay, in an insecure scenario you don't need to change permissions... (-: > > Okay, it's not the fault of devfs core, but why are drivers > > registering their nodes this way? > > Convenience. Is there a real problem with the relaxed default? On > most Unix systems I've used, the tape devices are rw-rw-rw-. Most Unix systems I've used had root exploits which you can get from securityfocus.com. (-: That's not the point. I think you know pam_console. In my opinion the idea behind pam_console is very powerful and needed. The distinction between net users and local users is a must on a standard workstation as devices like sound, video, removeable medias (especially writable ones) need protection from net users. Otherwise local users cant use these without possible interference from net users with can log in the same time. When no distinction is made (kernel treats net users the same as local users) you have to choose a strict default to get a secure environment. On a one user machine: log in as root... [-: > The sysadmin does not want to be bothered by user requests "can you > please give me access to the tape drive so I can back up my data?". Backup should be the task of the admin! And here we go: on panorama.hadiko.de I put all backups (system and homes) on tape. There are no local users except for me. Most of the users (including me) want to have a backup one the safe side while the tape is in the drive! To make a system insecure is an easy task. I can help the instance "sysadmin" here: $ chmod -R go+rw /dev Why should I and all the other "real" sysadmin be _bothered_ by insecure defaults? It's already hard enough to double check every step to _stay_ in a secure system... Further I've never seen a user backing up their data... <-: The same is true for the printer: as I don't get paper for free nobody should circumvent my printer policy by using the device directly. Regards, Robert From owner-devfs@oss.sgi.com Thu Sep 20 10:01:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KH1QR28447 for devfs-outgoing; Thu, 20 Sep 2001 10:01:26 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KH1Ke28444 for ; Thu, 20 Sep 2001 10:01:20 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8KH2Lh03467; Thu, 20 Sep 2001 11:02:21 -0600 Date: Thu, 20 Sep 2001 11:02:21 -0600 Message-Id: <200109201702.f8KH2Lh03467@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Robert Siemer Cc: devfs@oss.sgi.com Subject: Re: Default: unsecure In-Reply-To: <20010920184715A.siemer@panorama.hadiko.de> References: <20010920170320N.siemer@panorama.hadiko.de> <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> <20010920184715A.siemer@panorama.hadiko.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk Robert Siemer writes: > From: Richard Gooch > > Robert Siemer writes: > > > > Is there any reason to let the default permissions so unrestictive?? > > > E.g. line printer and scsi tape are world read-/writeable by default! > > > > Of course. Convenience. > > > > > Here you need to change them anyway, so it would be very reasonable > > > to start with root.root 600. > > > > What do you mean "here you need to change them anyway"? > > Okay, in an insecure scenario you don't need to change permissions... > (-: I don't think r/w access to a tape device really qualifies as "insecure". > > > Okay, it's not the fault of devfs core, but why are drivers > > > registering their nodes this way? > > > > Convenience. Is there a real problem with the relaxed default? On > > most Unix systems I've used, the tape devices are rw-rw-rw-. > > Most Unix systems I've used had root exploits which you can get from > securityfocus.com. (-: That's not the point. Not from r/w access to a tape device. > On a one user machine: log in as root... [-: I'm thinking more about public workstations in a research lab. > > The sysadmin does not want to be bothered by user requests "can you > > please give me access to the tape drive so I can back up my data?". > > Backup should be the task of the admin! Not if you have lots and lots of data. The admins backup home areas and software, but data is left to the users, who know what is worth backing up and what is not. > Why should I and all the other "real" sysadmin be _bothered_ by > insecure defaults? It's already hard enough to double check every > step to _stay_ in a secure system... Why should I and all the other real sysadmins who have hundreds of users be *bothered* with giving tape access every time it's asked for? > Further I've never seen a user backing up their data... <-: You'd be surprised. In any case, I don't want to argue about this. We have different perspectives. Let's agree to disagree. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Sep 20 13:32:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KKWmD02584 for devfs-outgoing; Thu, 20 Sep 2001 13:32:48 -0700 Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KKWie02579 for ; Thu, 20 Sep 2001 13:32:44 -0700 Received: from nce2.hadiko.de (hadince2.hadiko.uni-karlsruhe.de [172.20.32.2]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 15kAV0-0006o6-00; Thu, 20 Sep 2001 22:32:42 +0200 Received: from panorama.hadiko.de (hadii309.hadiko.uni-karlsruhe.de [172.20.44.69]) by nce2.hadiko.de (8.9.3/8.9.3) with SMTP id WAA13375 for ; Thu, 20 Sep 2001 22:32:41 +0200 (MET DST) Received: (qmail 14218 invoked from network); 20 Sep 2001 20:32:40 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Sep 2001 20:32:40 -0000 To: devfs@oss.sgi.com Subject: Re: Default: insecure From: Robert Siemer In-Reply-To: <200109201702.f8KH2Lh03467@vindaloo.ras.ucalgary.ca> References: <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> <20010920184715A.siemer@panorama.hadiko.de> <200109201702.f8KH2Lh03467@vindaloo.ras.ucalgary.ca> X-Mailer: Mew version 1.94b25 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010920223240K.siemer@panorama.hadiko.de> Date: Thu, 20 Sep 2001 22:32:40 +0200 X-Dispatcher: imput version 990425(IM115) Lines: 32 Sender: owner-devfs@oss.sgi.com Precedence: bulk From: Richard Gooch > Robert Siemer writes: > I'm thinking more about public workstations in a research lab. > > > > The sysadmin does not want to be bothered by user requests "can you > > > please give me access to the tape drive so I can back up my data?". > > > > Backup should be the task of the admin! > > Not if you have lots and lots of data. The admins backup home areas > and software, but data is left to the users, who know what is worth > backing up and what is not. > > > Why should I and all the other "real" sysadmin be _bothered_ by > > insecure defaults? It's already hard enough to double check every > > step to _stay_ in a secure system... > > Why should I and all the other real sysadmins who have hundreds of > users be *bothered* with giving tape access every time it's asked > for? > In any case, I don't want to argue about this. We have different > perspectives. Let's agree to disagree. I'm sorry for being so aggressive. - I see - your scenario is real. But how do you protect tape users from other users accessing their tape during backup (... or just before)? Regards, Robert From owner-devfs@oss.sgi.com Thu Sep 20 14:29:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KLT3503908 for devfs-outgoing; Thu, 20 Sep 2001 14:29:03 -0700 Received: from thalassa.informatimago.com (postfix@thalassa.informatimago.com [212.87.205.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KLSxe03905 for ; Thu, 20 Sep 2001 14:28:59 -0700 Received: by thalassa.informatimago.com (Postfix on SuSE Linux 7.1 (i386), from userid 1000) id D7B7960634; Thu, 20 Sep 2001 23:28:55 +0200 (CEST) From: Pascal Bourguignon To: Robert.Siemer@gmx.de Cc: devfs@oss.sgi.com In-reply-to: <20010920223240K.siemer@panorama.hadiko.de> (message from Robert Siemer on Thu, 20 Sep 2001 22:32:40 +0200) Subject: Re: Default: insecure Organization: InformatiMago. X-PGP-Key-ID: 0xEF5E9966 X-PGP-fingerprint: 00 F5 7B DB CA 51 8A AD 04 5B 6C DE 32 60 16 8E EF 5E 99 66 X-PGP-Key-URL: http://www.informatimago.com/pgpkey X-URL: http://www.informatimago.com/index X-Accept-Language: fr, es, en Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 Content-Language: en Reply-To: References: <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> <20010920184715A.siemer@panorama.hadiko.de> <200109201702.f8KH2Lh03467@vindaloo.ras.ucalgary.ca> <20010920223240K.siemer@panorama.hadiko.de> Message-Id: <20010920212855.D7B7960634@thalassa.informatimago.com> Date: Thu, 20 Sep 2001 23:28:55 +0200 (CEST) Sender: owner-devfs@oss.sgi.com Precedence: bulk > From: Robert Siemer > [...] > But how do you protect tape users from other users accessing their > tape during backup (... or just before)? > > > Regards, > Robert What about using flock on the tape devices? Wouldn't this work? On the other hand, if the tapes belong to their users, then the device should be assigned to the proper owner as soon as a tape is (physically) mounted on it. I don't know any mechanism in unix to do that other than "chown $USER $TAPEDEVICE" before mounting the tape. The question is: How do you assign a tape device to a user? -- __Pascal_Bourguignon__ (o_ Software patents are endangering () ASCII ribbon against html email //\ the computer industry all around /\ and Microsoft attachments. V_/ the world http://lpf.ai.mit.edu/ 1962:DO20I=1.100 2001:my($f)=`fortune`; http://petition.eurolinux.org/ -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/IT d? s++:++(+++)>++ a C+++ UB+++L++++$S+X++++>$ P- L+++ E++ W++ N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+) DI+++ D++ G++ e+++ h+(++) r? y---? UF++++ ------END GEEK CODE BLOCK------ From owner-devfs@oss.sgi.com Thu Sep 20 15:00:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KM0JE04675 for devfs-outgoing; Thu, 20 Sep 2001 15:00:19 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KM0De04671 for ; Thu, 20 Sep 2001 15:00:13 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8KM1Df06342; Thu, 20 Sep 2001 16:01:13 -0600 Date: Thu, 20 Sep 2001 16:01:13 -0600 Message-Id: <200109202201.f8KM1Df06342@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Robert Siemer Cc: devfs@oss.sgi.com Subject: Re: Default: insecure In-Reply-To: <20010920223240K.siemer@panorama.hadiko.de> References: <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> <20010920184715A.siemer@panorama.hadiko.de> <200109201702.f8KH2Lh03467@vindaloo.ras.ucalgary.ca> <20010920223240K.siemer@panorama.hadiko.de> Sender: owner-devfs@oss.sgi.com Precedence: bulk Robert Siemer writes: > I'm sorry for being so aggressive. - I see - your scenario is real. > But how do you protect tape users from other users accessing their > tape during backup (... or just before)? The tape drivers I've seen lock the device. In other words, while you're doing your backup/restore, someone else can't use the device. As for the "just before", something like PAM is one solution. A better solution is a suid-root programme that "allocates" the tape device (by changing ownership and permissions), and "deallocates" upon programme exit. Of course, now you have to deal with the issue of users locking up the tape device for long periods, blocking others. There's no perfect solution here, since there is a single physical resource which you are trying to share between users. A certain level of trust/co-operation is required. And given that, the simplest approach, which is good for 99% of uses, is rw-rw-rw- access, combined with the existing "one opener" behaviour of the driver. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Sep 20 15:03:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KM33r04741 for devfs-outgoing; Thu, 20 Sep 2001 15:03:03 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KM2ke04737 for ; Thu, 20 Sep 2001 15:02:47 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8KM3R806364; Thu, 20 Sep 2001 16:03:27 -0600 Date: Thu, 20 Sep 2001 16:03:27 -0600 Message-Id: <200109202203.f8KM3R806364@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Cc: Robert.Siemer@gmx.de, devfs@oss.sgi.com Subject: Re: Default: insecure In-Reply-To: <20010920212855.D7B7960634@thalassa.informatimago.com> References: <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> <20010920184715A.siemer@panorama.hadiko.de> <200109201702.f8KH2Lh03467@vindaloo.ras.ucalgary.ca> <20010920223240K.siemer@panorama.hadiko.de> <20010920212855.D7B7960634@thalassa.informatimago.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Pascal Bourguignon writes: > > From: Robert Siemer > > [...] > > But how do you protect tape users from other users accessing their > > tape during backup (... or just before)? > > What about using flock on the tape devices? Wouldn't this work? Not needed to protect against other openers (only one open at a time is allowed). And flocks are lost when you close the file descriptor. Also, flocks are advisory only (in general). > On the other hand, if the tapes belong to their users, then the device > should be assigned to the proper owner as soon as a tape is > (physically) mounted on it. I don't know any mechanism in unix to do > that other than "chown $USER $TAPEDEVICE" before mounting the tape. > > The question is: How do you assign a tape device to a user? chown(2). Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Sep 20 15:36:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8KMaAS05245 for devfs-outgoing; Thu, 20 Sep 2001 15:36:10 -0700 Received: from thalassa.informatimago.com (postfix@thalassa.informatimago.com [212.87.205.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8KMa5e05239 for ; Thu, 20 Sep 2001 15:36:05 -0700 Received: by thalassa.informatimago.com (Postfix on SuSE Linux 7.1 (i386), from userid 1000) id 3CE3C5D70B; Fri, 21 Sep 2001 00:36:03 +0200 (CEST) From: Pascal Bourguignon To: rgooch@ras.ucalgary.ca Cc: Robert.Siemer@gmx.de, devfs@oss.sgi.com In-reply-to: <200109202203.f8KM3R806364@vindaloo.ras.ucalgary.ca> (message from Richard Gooch on Thu, 20 Sep 2001 16:03:27 -0600) Subject: Re: Default: insecure Organization: InformatiMago. X-PGP-Key-ID: 0xEF5E9966 X-PGP-fingerprint: 00 F5 7B DB CA 51 8A AD 04 5B 6C DE 32 60 16 8E EF 5E 99 66 X-PGP-Key-URL: http://www.informatimago.com/pgpkey X-URL: http://www.informatimago.com/index X-Accept-Language: fr, es, en Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Disposition: inline Content-Type: text/plain; charset=iso-8859-1 Content-Language: en Reply-To: References: <200109201531.f8KFVbP02796@vindaloo.ras.ucalgary.ca> <20010920184715A.siemer@panorama.hadiko.de> <200109201702.f8KH2Lh03467@vindaloo.ras.ucalgary.ca> <20010920223240K.siemer@panorama.hadiko.de> <20010920212855.D7B7960634@thalassa.informatimago.com> <200109202203.f8KM3R806364@vindaloo.ras.ucalgary.ca> Message-Id: <20010920223603.3CE3C5D70B@thalassa.informatimago.com> Date: Fri, 21 Sep 2001 00:36:03 +0200 (CEST) Sender: owner-devfs@oss.sgi.com Precedence: bulk > Date: Thu, 20 Sep 2001 16:03:27 -0600 > From: Richard Gooch > > Pascal Bourguignon writes: > > > From: Robert Siemer > > > [...] > > > But how do you protect tape users from other users accessing their > > > tape during backup (... or just before)? > > > > What about using flock on the tape devices? Wouldn't this work? > > Not needed to protect against other openers (only one open at a time > is allowed). And flocks are lost when you close the file descriptor. > Also, flocks are advisory only (in general). > > > On the other hand, if the tapes belong to their users, then the device > > should be assigned to the proper owner as soon as a tape is > > (physically) mounted on it. I don't know any mechanism in unix to do > > that other than "chown $USER $TAPEDEVICE" before mounting the tape. > > > > The question is: How do you assign a tape device to a user? > > chown(2). Thank you :-) I suggested chown(1) just one line above. My question was to Robert, on the policy plan. Depending on the policy adopted to assign tape devices to the users, one could develop some scripts with a strategically placed "chown $USER $TAPEDEVICE", to automate the process. -- __Pascal_Bourguignon__ (o_ Software patents are endangering () ASCII ribbon against html email //\ the computer industry all around /\ and Microsoft attachments. V_/ the world http://lpf.ai.mit.edu/ 1962:DO20I=1.100 2001:my($f)=`fortune`; http://petition.eurolinux.org/ -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/IT d? s++:++(+++)>++ a C+++ UB+++L++++$S+X++++>$ P- L+++ E++ W++ N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+) DI+++ D++ G++ e+++ h+(++) r? y---? UF++++ ------END GEEK CODE BLOCK------ From owner-devfs@oss.sgi.com Thu Sep 20 22:15:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8L5FHe12323 for devfs-outgoing; Thu, 20 Sep 2001 22:15:17 -0700 Received: from inf.ufrgs.br (puma.inf.ufrgs.br [143.54.11.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8L5FFe12320 for ; Thu, 20 Sep 2001 22:15:15 -0700 Received: from jacui (jacui [143.54.11.130]) by inf.ufrgs.br (8.11.0/8.11.3) with ESMTP id f8L5D8n30482; Fri, 21 Sep 2001 02:13:08 -0300 Date: Fri, 21 Sep 2001 02:15:47 -0300 (EST) From: Roberto Jung Drebes X-Sender: drebes@jacui To: Pascal Bourguignon cc: devfs@oss.sgi.com Subject: Re: Default: insecure In-Reply-To: <20010920223603.3CE3C5D70B@thalassa.informatimago.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Fri, 21 Sep 2001, Pascal Bourguignon wrote: > Thank you :-) I suggested chown(1) just one line above. My question > was to Robert, on the policy plan. Depending on the policy adopted to > assign tape devices to the users, one could develop some scripts with > a strategically placed "chown $USER $TAPEDEVICE", to automate the > process. Isn't it what pam_console(8) do to you? -- Roberto Jung Drebes Porto Alegre, RS - Brasil http://www.inf.ufrgs.br/~drebes/ From owner-devfs@oss.sgi.com Mon Sep 24 20:11:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8P3BEC09076 for devfs-outgoing; Mon, 24 Sep 2001 20:11:14 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8P3AgD09068 for ; Mon, 24 Sep 2001 20:10:42 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8P39vh18306; Mon, 24 Sep 2001 21:09:57 -0600 Date: Mon, 24 Sep 2001 21:09:57 -0600 Message-Id: <200109250309.f8P39vh18306@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: torvalds@transmeta.com Cc: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] sd-many for 2.4.10 Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, Linus. Here is my complete sd-many patch for 2.4.10. It's tested, it works and it's safe. Please apply. Patch generated against 2.4.10-pre14 but applies cleanly against 2.4.10. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca diff -urN linux-2.4.10-pre14/Documentation/Configure.help linux/Documentation/Configure.help --- linux-2.4.10-pre14/Documentation/Configure.help Sat Sep 22 00:26:10 2001 +++ linux/Documentation/Configure.help Sat Sep 22 00:36:08 2001 @@ -5453,6 +5453,17 @@ located on a SCSI disk. In this case, do not compile the driver for your SCSI host adapter (below) as a module either. +Many SCSI Discs support +CONFIG_SD_MANY + This allows you to support a very large number of SCSI discs + (approximately 2080). You will also need to set CONFIG_DEVFS_FS=y + later. This option may consume all unassigned block majors + (i.e. those which do not have an allocation in + Documentation/devices.txt). Enabling this will consume a few extra + kilobytes of kernel memory. + + Unless you have a large storage array, say N. + Extra SCSI Disks CONFIG_SD_EXTRA_DEVS This controls the amount of additional space allocated in tables for diff -urN linux-2.4.10-pre14/drivers/scsi/Config.in linux/drivers/scsi/Config.in --- linux-2.4.10-pre14/drivers/scsi/Config.in Sat Sep 22 00:26:14 2001 +++ linux/drivers/scsi/Config.in Sat Sep 22 00:40:04 2001 @@ -3,7 +3,8 @@ dep_tristate ' SCSI disk support' CONFIG_BLK_DEV_SD $CONFIG_SCSI if [ "$CONFIG_BLK_DEV_SD" != "n" ]; then - int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 + bool ' Many (~2080) SCSI discs support (requires devfs)' CONFIG_SD_MANY + int ' Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI diff -urN linux-2.4.10-pre14/drivers/scsi/hosts.h linux/drivers/scsi/hosts.h --- linux-2.4.10-pre14/drivers/scsi/hosts.h Thu Sep 20 22:33:51 2001 +++ linux/drivers/scsi/hosts.h Sat Sep 22 00:27:45 2001 @@ -506,9 +506,8 @@ const char * tag; struct module * module; /* Used for loadable modules */ unsigned char scsi_type; - unsigned int major; - unsigned int min_major; /* Minimum major in range. */ - unsigned int max_major; /* Maximum major in range. */ + unsigned int *majors; /* Array of majors used by driver */ + unsigned int num_majors; /* Number of majors used by driver */ unsigned int nr_dev; /* Number currently attached */ unsigned int dev_noticed; /* Number of devices detected. */ unsigned int dev_max; /* Current size of arrays */ diff -urN linux-2.4.10-pre14/drivers/scsi/osst.c linux/drivers/scsi/osst.c --- linux-2.4.10-pre14/drivers/scsi/osst.c Thu Jul 19 22:18:15 2001 +++ linux/drivers/scsi/osst.c Sat Sep 22 00:27:45 2001 @@ -160,7 +160,6 @@ name: "OnStream tape", tag: "osst", scsi_type: TYPE_TAPE, - major: OSST_MAJOR, detect: osst_detect, init: osst_init, attach: osst_attach, diff -urN linux-2.4.10-pre14/drivers/scsi/scsi_lib.c linux/drivers/scsi/scsi_lib.c --- linux-2.4.10-pre14/drivers/scsi/scsi_lib.c Sun Aug 12 11:51:42 2001 +++ linux/drivers/scsi/scsi_lib.c Sat Sep 22 00:27:45 2001 @@ -788,25 +788,10 @@ * Search for a block device driver that supports this * major. */ - if (spnt->blk && spnt->major == major) { - return spnt; - } - /* - * I am still not entirely satisfied with this solution, - * but it is good enough for now. Disks have a number of - * major numbers associated with them, the primary - * 8, which we test above, and a secondary range of 7 - * different consecutive major numbers. If this ever - * becomes insufficient, then we could add another function - * to the structure, and generalize this completely. - */ - if( spnt->min_major != 0 - && spnt->max_major != 0 - && major >= spnt->min_major - && major <= spnt->max_major ) - { - return spnt; - } + int i; + if (!spnt->blk || !spnt->majors) continue; + for (i = 0; i < spnt->num_majors; ++i) + if (spnt->majors[i] == major) return spnt; } return NULL; } diff -urN linux-2.4.10-pre14/drivers/scsi/sd.c linux/drivers/scsi/sd.c --- linux-2.4.10-pre14/drivers/scsi/sd.c Sat Sep 22 00:26:14 2001 +++ linux/drivers/scsi/sd.c Sat Sep 22 00:37:11 2001 @@ -28,6 +28,8 @@ * * Modified by Alex Davis * Fix problem where removable media could be ejected after sd_open. + * + * Modified by Richard Gooch rgooch@atnf.csiro.au to support >128 discs. */ #include @@ -65,7 +67,11 @@ * static const char RCSid[] = "$Header:"; */ -#define SD_MAJOR(i) (!(i) ? SCSI_DISK0_MAJOR : SCSI_DISK1_MAJOR-1+(i)) +#ifdef CONFIG_SD_MANY +# define SD_MAJOR(i) sd_template.majors[(i)] +#else +# define SD_MAJOR(i) (!(i) ? SCSI_DISK0_MAJOR : SCSI_DISK1_MAJOR-1+(i)) +#endif #define SCSI_DISKS_PER_MAJOR 16 #define SD_MAJOR_NUMBER(i) SD_MAJOR((i) >> 8) @@ -77,6 +83,14 @@ #define MAX_RETRIES 5 +#ifdef CONFIG_SD_MANY +# define sdmalloc(size) vmalloc((size)) +# define sdfree(ptr) vfree((ptr)) +#else +# define sdmalloc(size) kmalloc((size),GFP_ATOMIC) +# define sdfree(ptr) kfree((ptr)) +#endif + /* * Time out in seconds for disks and Magneto-opticals (which are slower). */ @@ -109,12 +123,6 @@ name:"disk", tag:"sd", scsi_type:TYPE_DISK, - major:SCSI_DISK0_MAJOR, - /* - * Secondary range of majors that this driver handles. - */ - min_major:SCSI_DISK1_MAJOR, - max_major:SCSI_DISK7_MAJOR, blk:1, detect:sd_detect, init:sd_init, @@ -124,6 +132,19 @@ init_command:sd_init_command, }; +#ifdef CONFIG_SD_MANY +static inline int sd_devnum_to_index (int devnum) +{ + int i, major = MAJOR (devnum); + + for (i = 0; i < sd_template.num_majors; ++i) + { + if (sd_template.majors[i] != major) continue; + return (i << 4) | (MINOR (devnum) >> 4); + } + return -ENODEV; +} +#endif static void rw_intr(Scsi_Cmnd * SCpnt); @@ -1049,6 +1070,43 @@ return i; } +static int sd_alloc_majors (void) +/* Allocate as many majors as required + */ +{ + int i, major; + + if ( ( sd_template.majors = + kmalloc (sizeof *sd_template.majors * N_USED_SD_MAJORS, + GFP_KERNEL) ) == NULL ) { + printk ("sd.c: unable to allocate major array\n"); + return -ENOMEM; + } + sd_template.majors[0] = SCSI_DISK0_MAJOR; + for (i = 1; (i < N_USED_SD_MAJORS) && (i = N_SD_PREASSIGNED_MAJORS) && (i < N_USED_SD_MAJORS); ++i) { + if ( ( major = devfs_alloc_major (DEVFS_SPECIAL_BLK) ) < 0 ) { + printk (KERN_WARNING __FUNCTION__ "() major[%d] allocation failed\n", i); + break; + } + sd_template.majors[i] = major; + } + sd_template.dev_max = i * SCSI_DISKS_PER_MAJOR; + sd_template.num_majors = i; + return 0; +} /* End Function sd_alloc_majors */ + +static void sd_dealloc_majors (void) +/* Deallocate all the allocated majors + */ +{ + int i; + + for (i = sd_template.num_majors - 1; i >= N_SD_PREASSIGNED_MAJORS; --i) + devfs_dealloc_major (DEVFS_SPECIAL_BLK, sd_template.majors[i]); +} /* End Function sd_dealloc_majors */ + /* * The sd_init() function looks at all SCSI drives present, determines * their size, and reads partition table entries for them. @@ -1063,16 +1121,20 @@ if (sd_template.dev_noticed == 0) return 0; - if (!rscsi_disks) + if (!rscsi_disks) { + if ( in_interrupt () ) { + printk (__FUNCTION__ "(): called from interrupt\n"); + return 1; + } sd_template.dev_max = sd_template.dev_noticed + SD_EXTRA_DEVS; - - if (sd_template.dev_max > N_SD_MAJORS * SCSI_DISKS_PER_MAJOR) - sd_template.dev_max = N_SD_MAJORS * SCSI_DISKS_PER_MAJOR; + if ( sd_alloc_majors() ) return 1; + } if (!sd_registered) { for (i = 0; i < N_USED_SD_MAJORS; i++) { if (devfs_register_blkdev(SD_MAJOR(i), "sd", &sd_fops)) { printk("Unable to get major %d for SCSI disk\n", SD_MAJOR(i)); + sd_dealloc_majors(); return 1; } } @@ -1082,26 +1144,26 @@ if (rscsi_disks) return 0; - rscsi_disks = kmalloc(sd_template.dev_max * sizeof(Scsi_Disk), GFP_ATOMIC); + rscsi_disks = sdmalloc(sd_template.dev_max * sizeof(Scsi_Disk)); if (!rscsi_disks) goto cleanup_devfs; memset(rscsi_disks, 0, sd_template.dev_max * sizeof(Scsi_Disk)); /* for every (necessary) major: */ - sd_sizes = kmalloc((sd_template.dev_max << 4) * sizeof(int), GFP_ATOMIC); + sd_sizes = sdmalloc((sd_template.dev_max << 4) * sizeof(int)); if (!sd_sizes) goto cleanup_disks; memset(sd_sizes, 0, (sd_template.dev_max << 4) * sizeof(int)); - sd_blocksizes = kmalloc((sd_template.dev_max << 4) * sizeof(int), GFP_ATOMIC); + sd_blocksizes = sdmalloc((sd_template.dev_max << 4) * sizeof(int)); if (!sd_blocksizes) goto cleanup_sizes; - sd_hardsizes = kmalloc((sd_template.dev_max << 4) * sizeof(int), GFP_ATOMIC); + sd_hardsizes = sdmalloc((sd_template.dev_max << 4) * sizeof(int)); if (!sd_hardsizes) goto cleanup_blocksizes; - sd_max_sectors = kmalloc((sd_template.dev_max << 4) * sizeof(int), GFP_ATOMIC); + sd_max_sectors = sdmalloc((sd_template.dev_max << 4) * sizeof(int)); if (!sd_max_sectors) goto cleanup_max_sectors; @@ -1125,9 +1187,7 @@ * FIXME: should unregister blksize_size, hardsect_size and max_sectors when * the module is unloaded. */ - sd = kmalloc((sd_template.dev_max << 4) * - sizeof(struct hd_struct), - GFP_ATOMIC); + sd = sdmalloc((sd_template.dev_max << 4) * sizeof(struct hd_struct)); if (!sd) goto cleanup_sd; memset(sd, 0, (sd_template.dev_max << 4) * sizeof(struct hd_struct)); @@ -1172,21 +1232,22 @@ } kfree(sd_gendisks); cleanup_sd_gendisks: - kfree(sd); + sdfree(sd); cleanup_sd: - kfree(sd_max_sectors); + sdfree(sd_max_sectors); cleanup_max_sectors: - kfree(sd_hardsizes); + sdfree(sd_hardsizes); cleanup_blocksizes: - kfree(sd_blocksizes); + sdfree(sd_blocksizes); cleanup_sizes: - kfree(sd_sizes); + sdfree(sd_sizes); cleanup_disks: - kfree(rscsi_disks); + sdfree(rscsi_disks); cleanup_devfs: for (i = 0; i < N_USED_SD_MAJORS; i++) { devfs_unregister_blkdev(SD_MAJOR(i), "sd"); } + sd_dealloc_majors(); sd_registered--; return 1; } @@ -1385,16 +1446,17 @@ scsi_unregister_module(MODULE_SCSI_DEV, &sd_template); + sd_dealloc_majors(); for (i = 0; i < N_USED_SD_MAJORS; i++) devfs_unregister_blkdev(SD_MAJOR(i), "sd"); sd_registered--; if (rscsi_disks != NULL) { - kfree(rscsi_disks); - kfree(sd_sizes); - kfree(sd_blocksizes); - kfree(sd_hardsizes); - kfree((char *) sd); + sdfree(rscsi_disks); + sdfree(sd_sizes); + sdfree(sd_blocksizes); + sdfree(sd_hardsizes); + sdfree((char *) sd); } for (i = 0; i < N_USED_SD_MAJORS; i++) { del_gendisk(&sd_gendisks[i]); diff -urN linux-2.4.10-pre14/drivers/scsi/sd.h linux/drivers/scsi/sd.h --- linux-2.4.10-pre14/drivers/scsi/sd.h Thu Sep 20 22:33:51 2001 +++ linux/drivers/scsi/sd.h Sat Sep 22 00:27:45 2001 @@ -42,10 +42,14 @@ */ extern kdev_t sd_find_target(void *host, int tgt); -#define N_SD_MAJORS 8 +#define N_SD_PREASSIGNED_MAJORS 8 -#define SD_MAJOR_MASK (N_SD_MAJORS - 1) +#ifdef CONFIG_SD_MANY +#define SD_PARTITION(i) ((sd_devnum_to_index((i)) << 4) | ((i)&0x0f)) +#else +#define SD_MAJOR_MASK (N_SD_PREASSIGNED_MAJORS - 1) #define SD_PARTITION(i) (((MAJOR(i) & SD_MAJOR_MASK) << 8) | (MINOR(i) & 255)) +#endif #endif diff -urN linux-2.4.10-pre14/drivers/scsi/sg.c linux/drivers/scsi/sg.c --- linux-2.4.10-pre14/drivers/scsi/sg.c Sat Sep 22 00:26:14 2001 +++ linux/drivers/scsi/sg.c Sat Sep 22 00:27:45 2001 @@ -123,7 +123,6 @@ { tag:"sg", scsi_type:0xff, - major:SCSI_GENERIC_MAJOR, detect:sg_detect, init:sg_init, finish:sg_finish, diff -urN linux-2.4.10-pre14/drivers/scsi/sr.c linux/drivers/scsi/sr.c --- linux-2.4.10-pre14/drivers/scsi/sr.c Sat Sep 22 00:26:14 2001 +++ linux/drivers/scsi/sr.c Sat Sep 22 00:27:45 2001 @@ -69,12 +69,15 @@ static int sr_init_command(Scsi_Cmnd *); +static unsigned int sr_major = SCSI_CDROM_MAJOR; + static struct Scsi_Device_Template sr_template = { name:"cdrom", tag:"sr", scsi_type:TYPE_ROM, - major:SCSI_CDROM_MAJOR, + majors:&sr_major, + num_majors:1, blk:1, detect:sr_detect, init:sr_init, diff -urN linux-2.4.10-pre14/drivers/scsi/st.c linux/drivers/scsi/st.c --- linux-2.4.10-pre14/drivers/scsi/st.c Sun Aug 12 12:21:47 2001 +++ linux/drivers/scsi/st.c Sat Sep 22 00:27:45 2001 @@ -166,7 +166,6 @@ name:"tape", tag:"st", scsi_type:TYPE_TAPE, - major:SCSI_TAPE_MAJOR, detect:st_detect, init:st_init, attach:st_attach, diff -urN linux-2.4.10-pre14/include/linux/blk.h linux/include/linux/blk.h --- linux-2.4.10-pre14/include/linux/blk.h Thu Sep 20 22:33:32 2001 +++ linux/include/linux/blk.h Sat Sep 22 00:27:45 2001 @@ -144,7 +144,11 @@ #define DEVICE_NAME "scsidisk" #define TIMEOUT_VALUE (2*HZ) +#ifdef CONFIG_SD_MANY +#define DEVICE_NR(device) sd_devnum_to_index((device)) +#else #define DEVICE_NR(device) (((MAJOR(device) & SD_MAJOR_MASK) << (8 - 4)) + (MINOR(device) >> 4)) +#endif /* Kludge to use the same number for both char and block major numbers */ #elif (MAJOR_NR == MD_MAJOR) && defined(MD_DRIVER) From owner-devfs@oss.sgi.com Fri Sep 28 05:11:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8SCBwm10079 for devfs-outgoing; Fri, 28 Sep 2001 05:11:58 -0700 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8SCBuD10073 for ; Fri, 28 Sep 2001 05:11:56 -0700 Received: from ix.netcom.com (user-2injk8n.dialup.mindspring.com [165.121.209.23]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id IAA07144 for ; Fri, 28 Sep 2001 08:11:54 -0400 (EDT) Message-ID: <3BB46819.3060509@ix.netcom.com> Date: Fri, 28 Sep 2001 08:07:53 -0400 From: C R Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en-us MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: devfs newbie: dissapearing or somtimes not created cdrom Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk I am using the SGI xfs kernel 2.4.2-SGI_XFS_1.0smp with devfs. If I boot with a cdrom in the drive, the system comes up with the drive mounted and working. If I boot without a cdrom in the drive, I get no entry in /dev/cdroms, and hence no working cdrom. Likewise if I unmount a cdrom after booting and leave the drive empty for a number of hours, the device /dev/cdroms/.... vanishes and I am once again without my cdrom drive. What do I have to do to either keep the device from dissapearing or how do I (re-)create it in the event it does not exist. This does not seem to be in the FAQ. Thanks for a clue, Cliff From owner-devfs@oss.sgi.com Fri Sep 28 05:47:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8SClJI10818 for devfs-outgoing; Fri, 28 Sep 2001 05:47:19 -0700 Received: from hotmail.com (f145.law11.hotmail.com [64.4.17.145]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8SClGD10815 for ; Fri, 28 Sep 2001 05:47:16 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 28 Sep 2001 05:47:11 -0700 Received: from 194.117.133.196 by lw11fd.law11.hotmail.msn.com with HTTP; Fri, 28 Sep 2001 12:47:11 GMT X-Originating-IP: [194.117.133.196] From: "Rob MacGregor" To: devfs@oss.sgi.com Subject: Re: devfs newbie: dissapearing or somtimes not created cdrom Date: Fri, 28 Sep 2001 12:47:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Sep 2001 12:47:11.0422 (UTC) FILETIME=[B103D5E0:01C1481B] Sender: owner-devfs@oss.sgi.com Precedence: bulk >From: C R Johnson > >I am using the SGI xfs kernel 2.4.2-SGI_XFS_1.0smp with devfs. > >If I boot with a cdrom in the drive, the system comes up with the drive >mounted and working. >If I boot without a cdrom in the drive, I get no entry in /dev/cdroms, >and hence no working cdrom. >Likewise if I unmount a cdrom after booting and leave the drive empty >for a number of hours, the device /dev/cdroms/.... >vanishes and I am once again without my cdrom drive. > >What do I have to do to either keep the device from dissapearing or how >do I (re-)create it in the event it does not exist. > >This does not seem to be in the FAQ. I suspect you'll find that the cdrom drive support is compiled as a module. When the module hasn't been used for some time it'll be removed and devfs will unregister it. That's what happened to me with my printer and tape drive. However reloading the modules solved this. The solutions I found are: 1) Compile into the kernel. 2) Have the module load without the autoclean flag (put them in /etc/modules, probably). -- Rob | Please ask questions the smart way: http://www.tuxedo.org/~esr/faqs/smart-questions.html Please don't CC me on anything sent to mailing lists or send me email directly unless it's a privacy issue, thanks. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-devfs@oss.sgi.com Fri Sep 28 09:05:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8SG55115482 for devfs-outgoing; Fri, 28 Sep 2001 09:05:05 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8SG51D15479 for ; Fri, 28 Sep 2001 09:05:01 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f8SG4mb32561; Fri, 28 Sep 2001 10:04:48 -0600 Date: Fri, 28 Sep 2001 10:04:48 -0600 Message-Id: <200109281604.f8SG4mb32561@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Rob MacGregor" Cc: devfs@oss.sgi.com Subject: Re: devfs newbie: dissapearing or somtimes not created cdrom In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Rob MacGregor writes: > >From: C R Johnson > > > >I am using the SGI xfs kernel 2.4.2-SGI_XFS_1.0smp with devfs. > > > >If I boot with a cdrom in the drive, the system comes up with the drive > >mounted and working. > >If I boot without a cdrom in the drive, I get no entry in /dev/cdroms, > >and hence no working cdrom. > >Likewise if I unmount a cdrom after booting and leave the drive empty > >for a number of hours, the device /dev/cdroms/.... > >vanishes and I am once again without my cdrom drive. > > > >What do I have to do to either keep the device from dissapearing or how > >do I (re-)create it in the event it does not exist. > > > >This does not seem to be in the FAQ. > > I suspect you'll find that the cdrom drive support is compiled as a module. > When the module hasn't been used for some time it'll be removed and devfs > will unregister it. That's what happened to me with my printer and tape > drive. However reloading the modules solved this. > > The solutions I found are: > > 1) Compile into the kernel. > 2) Have the module load without the autoclean flag (put them in > /etc/modules, probably). You can also configure devfsd to autoload the module, so that when you attempt to access /dev/cdroms or /dev/cdroms/... the appropriate module(s) get loaded. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Sep 28 11:02:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8SI2Qc18098 for devfs-outgoing; Fri, 28 Sep 2001 11:02:26 -0700 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8SI2FD18093 for ; Fri, 28 Sep 2001 11:02:15 -0700 Received: from freeengineer.org (user-2injk29.dialup.mindspring.com [165.121.208.73]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA15262 for ; Fri, 28 Sep 2001 14:02:13 -0400 (EDT) Message-ID: <3BB4BA32.3070704@freeengineer.org> Date: Fri, 28 Sep 2001 13:58:10 -0400 From: C R Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en-us MIME-Version: 1.0 To: devfs Subject: Re: devfs newbie: dissapearing or somtimes not created cdrom References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk Rob MacGregor wrote: > > I suspect you'll find that the cdrom drive support is compiled as a > module. When the module hasn't been used for some time it'll be > removed and devfs will unregister it. That's what happened to me with > my printer and tape drive. However reloading the modules solved this. > Reloading the modules does not work for me. Here are some things I noticed, - from /var/log/messages when devfsd unloaded: Sep 27 23:50:00 pigpen devfsd[19]: action_compat: error unlinking: "cdrom0"^INsuch file or directory It really looks like that, "^I and all". - unloading and reloading the cdrom driver changes nothing: [root@pigpen cliff]# /sbin/modprobe -r sr_mod [root@pigpen cliff]# /sbin/lsmod Module Size Used by tuner 4256 1 (autoclean) bttv 62288 0 (autoclean) (unused) i2c-algo-bit 7392 1 (autoclean) [bttv] videodev 5248 2 (autoclean) [bttv] ppp_async 6928 1 (autoclean) ppp_generic 20208 4 (autoclean) [ppp_async] es1371 31712 0 ac97_codec 8864 0 [es1371] autofs 12112 1 (autoclean) 8139too 17040 1 (autoclean) ipchains 41440 0 (unused) tvaudio 8544 0 (autoclean) (unused) i2c-core 13008 0 (autoclean) [tuner bttv i2c-algo-bit tvaudio] sound 64912 0 (autoclean) (unused) soundcore 4784 6 (autoclean) [es1371 sound] usb-uhci 22784 0 (unused) usbcore 51824 1 [usb-uhci] aic7xxx 136976 3 sd_mod 11712 3 scsi_mod 98176 2 [aic7xxx sd_mod] [root@pigpen cliff]# /sbin/modprobe sr_mod [root@pigpen cliff]# /sbin/lsmod Module Size Used by sr_mod 15312 0 (unused) cdrom 28960 0 [sr_mod] tuner 4256 1 (autoclean) bttv 62288 0 (autoclean) (unused) i2c-algo-bit 7392 1 (autoclean) [bttv] videodev 5248 2 (autoclean) [bttv] ppp_async 6928 1 (autoclean) ppp_generic 20208 4 (autoclean) [ppp_async] es1371 31712 0 ac97_codec 8864 0 [es1371] autofs 12112 1 (autoclean) 8139too 17040 1 (autoclean) ipchains 41440 0 (unused) tvaudio 8544 0 (autoclean) (unused) i2c-core 13008 0 (autoclean) [tuner bttv i2c-algo-bit tvaudio] sound 64912 0 (autoclean) (unused) soundcore 4784 6 (autoclean) [es1371 sound] usb-uhci 22784 0 (unused) usbcore 51824 1 [usb-uhci] aic7xxx 136976 3 sd_mod 11712 3 scsi_mod 98176 3 [sr_mod aic7xxx sd_mod] [root@pigpen cliff]# mount /cdrom mount: special device /dev/hdb does not exist # ls -l /dev/hdb [root@pigpen cliff]ls: /dev/hdb: No such file or directory [root@pigpen cliff]# ls -l /dev/cdrom lr-xr-xr-x 1 root root 13 Sep 28 13:45 /dev/cdrom -> cdroms/cdrom0 [root@pigpen cliff]# ls -l /dev/cdrom lr-xr-xr-x 1 root root 13 Sep 28 13:45 /dev/cdrom -> cdroms/cdrom0 [root@pigpen cliff]# ls -l /dev/cdroms total 0 [root@pigpen cliff]# ls -l /dev/ide/cd/ total 0 [root@pigpen cliff]# ls -l /dev/ide/ cd hd host0 host2 [root@pigpen cliff]# ls -l /dev/ide/host0/bus0/target1/lun0/ total 0 Regards, Cliff