Alexander Viro writes:
> Devfs supports an interesting "feature" (read: gaping security
> hole waiting to happen). Namely, there is one (1) driver that asks
> for the following behaviour:
> its nodes (/dev/video1394/*) are created with root.root rw-rw-rw-
> opening a node sets (with feel^Wraces) ownership to that of opening
> task and mode to rw-------.
> if you close it, wait for dentry to be evicted and open it again -
> you get root.root rw-rw-rw- and it will stay that way after open().
>
> Now, I might try and guess WTF had been intended (reversion to
> permissions of the Beast upon final close() and subsequent open()
> acting as the first one), but even if it would behave that way...
The orginal use for DEVFS_FL_AUTO_OWNER was for PTY slaves,
particularly the BSD-style ones. It allows a non-suid root process to
open an unused PTY and be given ownership of it. Good for non-suid
xterms.
Later, I created DEVFS_FL_CURRENT_OWNER, and used that (in combination
with unregistering PTY slaves when the master is closed). That seemed
a cleaner approach.
> Just ask yourself what will happen to any program that relies on
> this behavior on a system where /dev is not on devfs. And that,
> BTW, is the setup suggested by vidoe1394 folks on their homepage.
>
> Now, I don't ask WTF had been smoked to produce that code - I don't
> want to know and it's probably illegal anywhere (if it isn't, it
> should be). The question is could we fscking please remove that
> idiocy? Unless somebody gives a good reason why behaviour of
> DEVFS_FL_AUTO_OWNER is _not_ a security hole - I'm submitting a
> patch that removes this crap in a couple of hours.
Well, I can't comment on the video1394 driver. I don't really know why
they are using DEVFS_FL_AUTO_OWNER. If their device node is safe to
have rw-rw-rw- (like with PTY slaves), then it's not a problem.
However, if the driver allows you to do Bad Things[tm] if you can read
or write to the device node, then the driver is buggy, and is abusing
DEVFS_FL_AUTO_OWNER.
So we should get input from the driver maintainer as to what the
intent is.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:55 EST