linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Viro <viro@math.psu.edu>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org, Richard Gooch <rgooch@ras.ucalgary.ca>
Subject: [RFC] killing DEVFS_FL_AUTO_OWNER
Date: Sun, 6 Oct 2002 14:55:36 -0400 (EDT)	[thread overview]
Message-ID: <Pine.GSO.4.21.0210061428540.25699-100000@weyl.math.psu.edu> (raw)

	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...

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.


             reply	other threads:[~2002-10-06 18:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-06 18:55 Alexander Viro [this message]
2002-10-06 19:32 ` [RFC] killing DEVFS_FL_AUTO_OWNER Richard Gooch
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=Pine.GSO.4.21.0210061428540.25699-100000@weyl.math.psu.edu \
    --to=viro@math.psu.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    --cc=torvalds@transmeta.com \
    /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).