lkml.org 
[lkml]   [1997]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] fix for /dev/full
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.111 / U:1.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site