Messages in this thread | | | Date | Wed, 10 Sep 1997 10:45:40 -0400 (EDT) | From | Nathan Bryant <> | Subject | Re: [PATCH] fix for /dev/full |
| |
On Tue, 9 Sep 1997, Wolfram Kleff wrote:
> OK, /dev/full take 3 ;-) > > There is still a problem with mode 622, > in really bad cases, the superuser can be fooled with /dev/full. > > I have included the following patch, which should fix ALL problems. > (Really paranoid) people might change /dev/full to 622, but > I think that 666 should work save and fine, too. > > Any problems left, any comments ?
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.
We can't expect everybody to get the mode on devices right; this is a problem that should be solved at the kernel level, not in userspace by changing permissions on devices.
[brain-damaged patch snipped]
Nathan Bryant nathan@nbryan71.dorm.usm.maine.edu nbryan71@mail.caps.maine.edu
| |