From: Richard Gooch <rgooch@ras.ucalgary.ca>
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] killing DEVFS_FL_AUTO_OWNER
Date: Sun, 6 Oct 2002 13:32:03 -0600 [thread overview]
Message-ID: <200210061932.g96JW3527255@vindaloo.ras.ucalgary.ca> (raw)
In-Reply-To: <Pine.GSO.4.21.0210061428540.25699-100000@weyl.math.psu.edu>
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
next prev parent reply other threads:[~2002-10-06 19:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-06 18:55 [RFC] killing DEVFS_FL_AUTO_OWNER Alexander Viro
2002-10-06 19:32 ` Richard Gooch [this message]
2002-10-06 20:07 ` Alexander Viro
2002-10-13 0:17 ` Richard Gooch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200210061932.g96JW3527255@vindaloo.ras.ucalgary.ca \
--to=rgooch@ras.ucalgary.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).