misc/42237: /dev/null permission issues

[mr.qweo%gmail.com@localhost]

>Number:         42237
>Category:       misc
>Synopsis:       /dev/null permission issues
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 27 14:10:00 +0000 2009
>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