Messages in this thread | | | From | (H. Peter Anvin) | Subject | Re: [PATCH] fix for /dev/full | Date | 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/
| |