NetBSD Problem Report #42237

From www@NetBSD.org  Tue Oct 27 14:07:04 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 3101363B902
	for <gnats-bugs@gnats.netbsd.org>; Tue, 27 Oct 2009 14:07:04 +0000 (UTC)
Message-Id: <20091027140703.8F3B763B8B6@www.NetBSD.org>
Date: Tue, 27 Oct 2009 14:07:03 +0000 (UTC)
From: mr.qweo@gmail.com
Reply-To: mr.qweo@gmail.com
To: gnats-bugs@NetBSD.org
Subject: /dev/null permission issues
X-Send-Pr-Version: www-1.0

>Number:         42237
>Category:       misc
>Synopsis:       /dev/null permission issues
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 27 14:10:00 +0000 2009
>Closed-Date:    Fri Dec 18 06:08:38 +0000 2009
>Last-Modified:  Wed Jan 27 23:35:02 +0000 2010
>Originator:     rider
>Release:        5.0.1
>Organization:
>Environment:
NetBSD stallion 5.0.1 NetBSD 5.0.1 (GENERIC) ...
>Description:
There are strange issues with /dev/null access permissions in a fresh installation of NetBSD/amd64. First, these (permissions) are nowhere near persistent even through I'm not using RAM-based file systems and there's no dynamic device node management in NetBSD altogether. Moreover, strange things (appear to?) happen: it looks like /dev/null permissions are being changed along the way (one day I found /dev/null it belonging to my primary group rather than to wheel, and I was nowhere near to claiming such kind authority over it :-) ). There were some other things like this, but since I'm unable to reproduce these, as well as the aforementioned situation, I wouldn't insist on their existence (at least as bugs of NetBSD and not my own :-) ), but I'm all too well able to reproduce continuous re-setting of /dev/null permissions (to 0600, root:wheel if you're interested), so let's focus on it.
>How-To-Repeat:
I guess that installing the last release of NetBSD/amd64 would be enough to experience the joy of working with the Great Black Hole blocked since my installation may be considered fresh. 

I suppose that indeed-existent impersistence-of-permissions-across-reboot takes place due to a bug in the shutdown sequence, because when I set the correct permissions using NetBSD installation medium, my setting survived the reboot into the installed system, but not the subsequent one(s). 
Matthew Mondor suggested that the bug may be related to grantpt(3), through according to the manual, it would set tty node mode to 0620 rather than to 0600 I'm facing.
>Fix:
Perhaps a ttyaction(5) entry like this may be considered a work-around (although I haven't got enough time to test this, as opposed to a partially-working one (with action of 'getty') that I "thought out" a couple of days ago):
 * * chmod a+rw /dev/null

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: misc/42237: /dev/null permission issues
Date: Tue, 27 Oct 2009 14:14:45 +0000

 On Tue, Oct 27, 2009 at 02:10:01PM +0000, mr.qweo@gmail.com wrote:
  > There are strange issues with /dev/null access permissions in a
  > fresh installation of NetBSD/amd64. First, these (permissions) are
  > nowhere near persistent even through I'm not using RAM-based file
  > systems and there's no dynamic device node management in NetBSD
  > altogether. Moreover, strange things (appear to?) happen: it looks
  > like /dev/null permissions are being changed along the way (one day
  > I found /dev/null it belonging to my primary group rather than to
  > wheel, and I was nowhere near to claiming such kind authority over
  > it :-) ). There were some other things like this, but since I'm
  > unable to reproduce these, as well as the aforementioned situation,
  > I wouldn't insist on their existence (at least as bugs of NetBSD
  > and not my own :-) ), but I'm all too well able to reproduce
  > continuous re-setting of /dev/null permissions (to 0600, root:wheel
  > if you're interested), so let's focus on it.

 I have seen this (or something very like it) and it was caused by
 this:

 lrwx------  1 dholland  notmp    9 Oct 27 10:16 .lesshst -> /dev/null

 in the home directory of a user with root access. (root's home
 directory probably "works" too.)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Lucio Albornoz <l.illanes@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: misc/42237: /dev/null permission issues
Date: Tue, 3 Nov 2009 00:39:38 +0100

 On Tue, Oct 27, 2009 at 02:10:01PM +0000, mr.qweo@gmail.com wrote:
 > There are strange issues with /dev/null access permissions in a
 > fresh installation of NetBSD [ ... ]. First, these (permissions)
 > are nowhere near persistent [ ... ] Moreover, strange things
 > (appear to?) happen: it looks like /dev/null permissions are
 > being changed along the way (one day I found /dev/null it belonging
 > to my primary group rather than to wheel, and I was nowhere near
 > to claiming such kind authority over it :-) ).
 Same issue as <http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/132367>
 perhaps?

 -- 
 This process can check if this value is zero, and if it is, it does
 something child-like.
 		-- Forbes Burkowski, Computer Science 454

From: "Greg A. Woods" <woods@planix.ca>
To: Lucio Albornoz <l.illanes@gmx.de>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>,
	misc-bug-people@netbsd.org
Subject: Re: misc/42237: /dev/null permission issues
Date: Mon, 02 Nov 2009 21:27:57 -0500

 --pgp-sign-Multipart_Mon_Nov__2_21:27:57_2009-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable

 At Tue, 3 Nov 2009 00:39:38 +0100, Lucio Albornoz <l.illanes@gmx.de> wrote:
 Subject: Re: misc/42237: /dev/null permission issues
 >=20
 > On Tue, Oct 27, 2009 at 02:10:01PM +0000, mr.qweo@gmail.com wrote:
 > > There are strange issues with /dev/null access permissions in a
 > > fresh installation of NetBSD [ ... ]. First, these (permissions)
 > > are nowhere near persistent [ ... ] Moreover, strange things
 > > (appear to?) happen: it looks like /dev/null permissions are
 > > being changed along the way (one day I found /dev/null it belonging
 > > to my primary group rather than to wheel, and I was nowhere near
 > > to claiming such kind authority over it :-) ).
 >=20
 > Same issue as <http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/132367>
 > perhaps?

 Anyone who makes a symlink point at /dev/null is just asking for big
 trouble, especially if it is any pathname that could ever be accessed in
 any way by any privileged process.

 That said though, I've always thought some of these important system
 device files should have something close to the "system immutable flag"
 (schg) set on them so that their permissions and ownerships cannot be
 changed during normal operation.

 --=20
 						Greg A. Woods
 						Planix, Inc.

 <woods@planix.com>       +1 416 218 0099        http://www.planix.com/

 --pgp-sign-Multipart_Mon_Nov__2_21:27:57_2009-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)

 iD8DBQBK75UtZn1xt3i/9H8RApyjAKCTNYaWrlEdlosXK458HW9y3CCzuACggDBq
 7E6ZPrfHtn08mIWHoNAe8ek=
 =HS68
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Mon_Nov__2_21:27:57_2009-1--

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: rider <mr.qweo@gmail.com>
Subject: Re: misc/42237: /dev/null permission issues
Date: Mon, 14 Dec 2009 02:57:26 +0000

 On Wed, Nov 04, 2009 at 08:58:38PM +0300, rider wrote:
  > > ?Anyone who makes a symlink point at /dev/null is just asking for big
  > > ?trouble, especially if it is any pathname that could ever be accessed in
  > > ?any way by any privileged process.
  > 
  > So, the correct way to get rid of less(1) history is LESSHISTFILE
  > environment variable setting of "-", but redirecting garbage to the
  > black hole is useful, so the flag is to be set by default indeed.

 I have found that the safest way to disable the behavior is to
 mkdir ~/.lesshst. This seems to prevent less from writing anything
 and doesn't cause it to leave a mess behind.

 I would argue that the misfeature should be turned off in less, but
 since less is a 3rd-party program this would be expensive from a
 documentation and user-expectations point of view. So it isn't likely
 to happen. If anyone wants it to happen badly enough, ask on
 tech-userlevel.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/42237: /dev/null permission issues
Date: Mon, 14 Dec 2009 03:45:00 +0000

 grumble. I'm supposed to know better than to forget to mail gnats.

    ------

 From: David Holland <dholland-bugs@netbsd.org>
 To: misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
 	netbsd-bugs@netbsd.org, mr.qweo@gmail.com
 Subject: Re: misc/42237: /dev/null permission issues
 Date: Mon, 14 Dec 2009 03:31:03 +0000

 On Mon, Dec 14, 2009 at 03:00:07AM +0000, David Holland wrote:
  >  I would argue that the misfeature should be turned off in less, but
  >  since less is a 3rd-party program this would be expensive from a
  >  documentation and user-expectations point of view. So it isn't likely
  >  to happen. If anyone wants it to happen badly enough, ask on
  >  tech-userlevel.

 On second thought, patching less so it won't attempt to write .lesshst
 over a non-regular file is straightforward and should solve the
 problem adequately.

 -- 
 David A. Holland
 dholland@netbsd.org

From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42237 CVS commit: src/usr.bin/less/less
Date: Mon, 14 Dec 2009 03:58:27 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Mon Dec 14 03:58:27 UTC 2009

 Modified Files:
 	src/usr.bin/less/less: cmdbuf.c

 Log Message:
 Don't attempt to read or write ~/.lesshst if it's not a regular file
 or a symlink to a regular file. Previously, symlinking to /dev/null
 would cause less to trash /dev/null if run with sufficient privileges,
 as seen in PR misc/42237.

 While the official way to disable .lesshst is to set an environment
 variable, that is problematic in some cases, such as single-user mode.
 A safer way to prevent even an unpatched less from writing anything
 out is to mkdir ~/.lesshst.


 To generate a diff of this commit:
 cvs rdiff -u -r1.7 -r1.8 src/usr.bin/less/less/cmdbuf.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->pending-pullups
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 14 Dec 2009 04:03:12 +0000
State-Changed-Why:
Fixed in -current, but this ought to go into the 5.x branch.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/42237 (/dev/null permission issues)
Date: Mon, 14 Dec 2009 04:18:19 +0000

 On Mon, Dec 14, 2009 at 04:03:13AM +0000, dholland@NetBSD.org wrote:
  > Fixed in -current, but this ought to go into the 5.x branch.

 pullup-5 #1194

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: pending-pullups->closed
State-Changed-By: snj@NetBSD.org
State-Changed-When: Fri, 18 Dec 2009 06:08:38 +0000
State-Changed-Why:
Pulled up.


From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42237 CVS commit: [netbsd-5] src/usr.bin/less/less
Date: Fri, 18 Dec 2009 06:06:56 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Fri Dec 18 06:06:56 UTC 2009

 Modified Files:
 	src/usr.bin/less/less [netbsd-5]: cmdbuf.c

 Log Message:
 Pull up following revision(s) (requested by dholland in ticket #1194):
 	usr.bin/less/less/cmdbuf.c: revision 1.8
 Don't attempt to read or write ~/.lesshst if it's not a regular file
 or a symlink to a regular file. Previously, symlinking to /dev/null
 would cause less to trash /dev/null if run with sufficient privileges,
 as seen in PR misc/42237.
 While the official way to disable .lesshst is to set an environment
 variable, that is problematic in some cases, such as single-user mode.
 A safer way to prevent even an unpatched less from writing anything
 out is to mkdir ~/.lesshst.


 To generate a diff of this commit:
 cvs rdiff -u -r1.7 -r1.7.24.1 src/usr.bin/less/less/cmdbuf.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: SAITOH Masanobu <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42237 CVS commit: src/sys/dev/pci
Date: Sun, 27 Dec 2009 20:36:38 +0000

 Module Name:	src
 Committed By:	msaitoh
 Date:		Sun Dec 27 20:36:38 UTC 2009

 Modified Files:
 	src/sys/dev/pci: if_wm.c

 Log Message:
 Fix the bug that ICH9 can't found a PHY. This fix is not good, but it's
 the same as e1000 driver... Fixes PR#42237


 To generate a diff of this commit:
 cvs rdiff -u -r1.183 -r1.184 src/sys/dev/pci/if_wm.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Stephen Borrill <sborrill@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42237 CVS commit: [netbsd-5] src/sys/dev/pci
Date: Wed, 27 Jan 2010 22:27:51 +0000

 Module Name:	src
 Committed By:	sborrill
 Date:		Wed Jan 27 22:27:47 UTC 2010

 Modified Files:
 	src/sys/dev/pci [netbsd-5]: if_wm.c if_wmreg.h if_wmvar.h pcidevs
 	    pcidevs.h pcidevs_data.h

 Log Message:
 Pull up the following revisions(s) (requested by msaitoh in ticket #1277):
 sys/dev/pci/if_wm.c		1.184-1.194
 sys/dev/pci/if_wmreg.h		1.29-1.35
 sys/dev/pci/if_wmvar.h		1.5-1.8
 sys/dev/pci/pcidevs		1.1006,1.1009-1.1010, 1.1012-1.1013 via patch
 sys/dev/pci/pcidevs.h		regen
 sys/dev/pci/pcidevs_data.h	regen
 sys/dev/mii/igphyreg.h		1.5
 sys/dev/mii/inbmphyreg.h	1.1

 - Add support for i82583V.
 - Add some ICH9 and ICH10 devices.
 - Add support for PCH.
 - Fix the bug that ICH9 can't found a PHY. Fixes PR#42237
 - Fix an incorrect test for WM_F_EEPROM_INVALID since rev. 1.183. Some old
   chips don't set EECD_EE_PRES.
 - Fix a bug that both WM_F_EEPROM_SPI and WM_F_EEPROM_FLASH are set.
 - Add a missing decrement for a timeout reported by Wolfgang Stukenbrock
   in PR#42422.
 - PBA setting for i82574 is not 12K but 20K.
 - Enable checking the management mode on 82574.
 - Fix the length of the delay() in wm_gmii_reset(). It fixed the problem that
   sometimes the driver misunderstood PHYs in mii_attach(). It was reported
   by MATSUI Yoshihiro. We observed it on ICH9.
 - Fix the checking of jumbo frame function
 - Remove the extra macro definition for the offset 0x1a in EEPROM.
 - Add missing break in wm_reset()...
 - Fix the offset of WMREG_PBS...
 - Make wm_reset() and wm_gmii_reset() close to e1000 driver.
   At least, this change make wm_attach() stable on ICH9.
 - Reset GMII interface after wm_reset() in wm_init().
 - Rework for assigning mii_{read,write}reg(). Use PCI product ID to identify
   the PHY.
 - Add code about LPLU(Low Power Link Up) function. It seems that we have to
   do the same work for ICH9.
 - Fixes the rx stall problem on 82578 by MANY workaround code. We need more
   work for 82577.


 To generate a diff of this commit:
 cvs rdiff -u -r1.162.4.11 -r1.162.4.12 src/sys/dev/pci/if_wm.c
 cvs rdiff -u -r1.24.20.3 -r1.24.20.4 src/sys/dev/pci/if_wmreg.h
 cvs rdiff -u -r1.2.46.1 -r1.2.46.2 src/sys/dev/pci/if_wmvar.h
 cvs rdiff -u -r1.962.4.9 -r1.962.4.10 src/sys/dev/pci/pcidevs \
     src/sys/dev/pci/pcidevs_data.h
 cvs rdiff -u -r1.963.4.9 -r1.963.4.10 src/sys/dev/pci/pcidevs.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Stephen Borrill <sborrill@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42237 CVS commit: [netbsd-5] src/sys/dev
Date: Wed, 27 Jan 2010 23:34:56 +0000

 Module Name:	src
 Committed By:	sborrill
 Date:		Wed Jan 27 23:34:52 UTC 2010

 Modified Files:
 	src/sys/dev/mii [netbsd-5]: igphyreg.h
 	src/sys/dev/pci [netbsd-5]: if_wm.c if_wmreg.h if_wmvar.h pcidevs
 	    pcidevs.h pcidevs_data.h
 Added Files:
 	src/sys/dev/mii [netbsd-5]: inbmphyreg.h

 Log Message:
 Pull up the following revisions(s) (requested by msaitoh in ticket #1277):
 sys/dev/pci/if_wm.c		1.184-1.194
 sys/dev/pci/if_wmreg.h		1.29-1.35
 sys/dev/pci/if_wmvar.h		1.5-1.8
 sys/dev/pci/pcidevs		1.1006,1.1009-1.1010, 1.1012-1.1013 via patch
 sys/dev/pci/pcidevs.h		regen
 sys/dev/pci/pcidevs_data.h	regen
 sys/dev/mii/igphyreg.h		1.5
 sys/dev/mii/inbmphyreg.h	1.1

 - Add support for i82583V.
 - Add some ICH9 and ICH10 devices.
 - Add support for PCH.
 - Fix the bug that ICH9 can't found a PHY. Fixes PR#42237
 - Fix an incorrect test for WM_F_EEPROM_INVALID since rev. 1.183. Some old
   chips don't set EECD_EE_PRES.
 - Fix a bug that both WM_F_EEPROM_SPI and WM_F_EEPROM_FLASH are set.
 - Add a missing decrement for a timeout reported by Wolfgang Stukenbrock
   in PR#42422.
 - PBA setting for i82574 is not 12K but 20K.
 - Enable checking the management mode on 82574.
 - Fix the length of the delay() in wm_gmii_reset(). It fixed the problem that
   sometimes the driver misunderstood PHYs in mii_attach(). It was reported
   by MATSUI Yoshihiro. We observed it on ICH9.
 - Fix the checking of jumbo frame function
 - Remove the extra macro definition for the offset 0x1a in EEPROM.
 - Add missing break in wm_reset()...
 - Fix the offset of WMREG_PBS...
 - Make wm_reset() and wm_gmii_reset() close to e1000 driver.
   At least, this change make wm_attach() stable on ICH9.
 - Reset GMII interface after wm_reset() in wm_init().
 - Rework for assigning mii_{read,write}reg(). Use PCI product ID to identify
   the PHY.
 - Add code about LPLU(Low Power Link Up) function. It seems that we have to
   do the same work for ICH9.
 - Fixes the rx stall problem on 82578 by MANY workaround code. We need more
   work for 82577.


 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.4.86.1 src/sys/dev/mii/igphyreg.h
 cvs rdiff -u -r0 -r1.1.2.2 src/sys/dev/mii/inbmphyreg.h
 cvs rdiff -u -r1.162.4.11 -r1.162.4.12 src/sys/dev/pci/if_wm.c
 cvs rdiff -u -r1.24.20.3 -r1.24.20.4 src/sys/dev/pci/if_wmreg.h
 cvs rdiff -u -r1.2.46.1 -r1.2.46.2 src/sys/dev/pci/if_wmvar.h
 cvs rdiff -u -r1.962.4.9 -r1.962.4.10 src/sys/dev/pci/pcidevs \
     src/sys/dev/pci/pcidevs_data.h
 cvs rdiff -u -r1.963.4.9 -r1.963.4.10 src/sys/dev/pci/pcidevs.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search