kern/139014: [null] /dev/null must be immunable to delete/unlink

Jason J. Hellenthal jhell at DataIX.net
Wed Apr 27 00:47:05 UTC 2011


Hi Robert,


On Tue, Apr 26, 2011 at 08:05:53PM -0400, Robert Lorentz wrote:
>Jason -
>
>Thanks for responding.  Also thanks for your help on freenode #freebsd (I'm on there as rcl sometimes)

And thank you too ;)

>
>I've run your script and this is what I get:
>

>FreeBSD 9.0-CURRENT #0 r220986: Sun Apr 24 08:25:28 UTC 2011     root at bsdvm.localdomain:/usr/obj/root/current/current/sys/GENERIC 
>BEFORE
>/dev/null: empty
>  File: "/dev/null"
>  Size: 0            FileType: Character Device
>  Mode: (0666/crw-rw-rw-)         Uid: (    0/    root)  Gid: (    0/   wheel)
>Device: 255,83886080   Inode: 23    Links: 1
>Access: Tue Apr 26 20:00:07 2011
>Modify: Tue Apr 26 20:00:01 2011
>Change: Tue Apr 26 20:00:01 2011
>crw-rw-rw-  1 root  wheel  -   0,  23 Apr 26 20:00 /dev/null
>AFTER
>/dev/null: empty
>  File: "/dev/null"
>  Size: 0            FileType: Character Device
>  Mode: (0777/crwxrwxrwx)         Uid: (    0/    root)  Gid: (    0/   wheel)
>Device: 255,83886080   Inode: 23    Links: 1
>Access: Tue Apr 26 20:00:08 2011
>Modify: Tue Apr 26 20:00:08 2011
>Change: Tue Apr 26 20:00:08 2011
>crwxrwxrwx  1 root  wheel  -   0,  23 Apr 26 20:00 /dev/null

>
>
>I see no real difference between our results except that my /dev/null starts as 666 and comes back as 777 and yours is always 777.  Again, I'm not clear on the meaning of this PR - I will abandon and move on.  It does seem that the PR should be either clarified or closed

I would suspect that the results coming back from this being run as root
are a result that the compiler usually outputs a binary with the
executable bit turned on for the umask of the user. Since root has a
umask of 022 by default its changing the mode of the file from its
default state to the 777. I had run this a few times before I gave that
output so that is why its consistent here for me.

If that's what the compiler is doing then the problem really is either
the user specifying the options or the program being compiled failed
resulting in what would normally be `a.out' but is now /dev/null being
removed.

The user here is obviously running/compiling as root and we cannot
prevent a user from shooting them self in the foot. It should be
possible without jumping through hoops to remove anything under /dev
unless the user has specified otherwise. It would probably be best to
patch the compiler to test the '-o' output file to see if its a regular
file or not before it removes it. I believe that is something that needs
to happen up-stream.

>
>
>On Apr 26, 2011, at 3:55 AM, Jason J. Hellenthal wrote:
>
>> 
>> Robert,
>> 
>> Sure this could be a good PR to verify but as the condition does not
>> exist on 8.2-STABLE as of today, I feel that you are just going to be
>> chasing a ghost in the machine.
>> 
>> This does not say that it wasn't relevant back then but as of now it is.
>> The PR didn't specify any realness to what was seen as I can tell from
>> reading it over it just says it disappeared and there could be many
>> possible reasons for that happening that fall back to the user in the
>> chair.
>> 
>> Attached is output from the script with a little more verbosity to show
>> its current status. 
>> 
>> If the same can still be reproduced on a recent -CURRENT system then
>> so-be-it but otherwise this can be closed.
>> 
>> On Tue, Apr 26, 2011 at 02:50:10AM +0000, Robert Lorentz wrote:
>>> The following reply was made to PR kern/139014; it has been noted by GNATS.
>>> 
>>> From: Robert Lorentz <robert.lorentz at gmail.com>
>>> To: bug-followup at FreeBSD.org,
>>> fluffy at FreeBSD.org
>>> Cc:  
>>> Subject: Re: kern/139014: [null] /dev/null must be immunable to delete/unlink
>>> Date: Mon, 25 Apr 2011 22:19:47 -0400
>>> 
>>> I've just started poking around the PR's to try to learn and help out, =
>>> and this one looked like a good first try..
>>> 
>>> Sure enough, as root on 9.0 -CURRENT I can "rm /dev/null" and it does =
>>> unlink and is missing.  However, I just recreate it with mknod /dev/null =
>>> c 0 6 ..  the behavior is identical on 8.2-RELEASE.
>>> 
>>> Am I missing something here?  Is there some kind of new default behavior =
>>> that should be implemented here?=20=
>> 
>> -- 
>> 
>> Regards,
>> Jason J. Hellenthal
>> 
>> <test.txt><test.sh>
>


-- 

 Regards, (jhell)
 Jason Hellenthal



More information about the freebsd-bugs mailing list