Re: [PATCH] fix for /dev/full

Nathan Bryant (
Wed, 10 Sep 1997 10:45:40 -0400 (EDT)

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