Re: [PATCH] fix for /dev/full

H. Peter Anvin (
10 Sep 1997 23:43:43 GMT

Followup to: <>
By author: Nathan Bryant <>
In newsgroup:
> 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...


    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See 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