Re: [PATCH] fix for /dev/full

H. Peter Anvin (hpa@transmeta.com)
10 Sep 1997 23:43:43 GMT


Followup to: <Pine.LNX.3.95.970910103425.3535B-100000@nbryan71.dorm.usm.maine.edu>
By author: Nathan Bryant <nathan@nbryan71.dorm.usm.maine.edu>
In newsgroup: linux.dev.kernel
>
> Yes, this is wrong, wrong, wrong! As hpa pointed out, this
> uninitialized-buffer behavior of /dev/full changes the semantics
> of read() in a dangerous way. I can only say that writing a program
> that depends on it is an extremely crocky design. Nobody should
> need it. Reading from /dev/full should zero the buffer under _all_
> circumstances (or perhaps mimic /dev/null).
>
> What if the daemon opens the device as root, then calls setuid()? While
> that might not be an incredibly good thing to do, I'm sure there's some
> program out there that does it and it might not be a security problem
> under normal circumstances, but if we throw in /dev/full, we're opening a
> whole new can of worms... even with your patch we've _still_ got a ticking
> time bomb here.
>

One issue is also inherited file descriptors, e.g.:

sendmail me < /dev/full

... and the like...

-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
Always looking for a few good BOsFH.  **  Linux - the OS of global cooperation
        I am Baha'i -- ask me about it or see http://www.bahai.org/