public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ted Ts'o" <tytso@mit.edu>
To: Greg KH <greg@kroah.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Vasiliy Kulikov <segoon@openwall.com>,
	Eric Paris <eparis@parisplace.org>,
	kernel-hardening@lists.openwall.com, Valdis.Kletnieks@vt.edu,
	linux-kernel@vger.kernel.org,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-security-module@vger.kernel.org
Subject: Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts
Date: Tue, 8 Nov 2011 15:07:35 -0500	[thread overview]
Message-ID: <20111108200735.GM24234@thunk.org> (raw)
In-Reply-To: <20111107234546.GA5835@kroah.com>

On Mon, Nov 07, 2011 at 03:45:46PM -0800, Greg KH wrote:
> > As I mentioned at the kernel summit, I'd like revoke along with a
> > formal notification from block devices that get ejected to the file
> > system layer, and the file system should be able to call a VFS library
> > function which revokes all open file descriptor on the ejected block
> > device.  It would result in much cleaner handling at the file system
> > level when a USB storage device gets pulled.
> 
> So you want revoke() on a block device to do what?  The same thing as
> disconnecting it from the hardware level?

No, what I meant is that a disconnect at the hardware level should
lead to notification to the file system via a call to struct super
operations function.  And then the file system can use that callback
(call it super->s_ops->device_ejected) to call revoke on all of the
open files on the file system.

If we were to implement a revoke(2) system call (as opposed to just
VFS functionality callable from kernel code), it should probably do
what revoke(2) does on other Unix systems:

     The revoke() system call invalidates all current open file
     descriptors in the system for the file named by path.  Subsequent
     operations on any such descriptors fail, with the exceptions that
     a read() from a character device file which has been revoked
     returns a count of zero (end of file), and a close() system call
     will succeed.  If the file is a special file for a device which
     is open, the device close function is called as if all open
     references to the file had been closed.

     Access to a file may be revoked only by its owner or the super
     user.  The revoke() system call is currently supported only for
     block and character special device files.  It is normally used to
     prepare a terminal device for a new login session, preventing any
     access by a previous user of the terminal.

The revoke functionality I was talking about is a way to disconnect a
file descriptor from the mounted file system, since when the device
that backed it has disappeared, the file system should disappear as
well.  What should be left are file descriptors that return an error
when read or written, and which are administratively managed by the
VFS layer, with all of the file system's refcounts appropriate
decremented, such that if it were loaded as a module, the fs module
could be safely unloaded.  

      	 					- Ted


  reply	other threads:[~2011-11-08 20:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07 17:45 [PATCH] proc: restrict access to /proc/interrupts Vasiliy Kulikov
2011-11-07 18:06 ` Valdis.Kletnieks
2011-11-07 19:01   ` Vasiliy Kulikov
2011-11-07 19:18     ` H. Peter Anvin
2011-11-07 19:29       ` [kernel-hardening] " Vasiliy Kulikov
2011-11-07 19:48         ` Eric Paris
2011-11-07 19:50           ` H. Peter Anvin
2011-11-07 20:11             ` Vasiliy Kulikov
2011-11-07 20:47               ` H. Peter Anvin
2011-11-07 21:23                 ` Linus Torvalds
2011-11-07 21:35                   ` H. Peter Anvin
2011-11-07 23:07                     ` Linus Torvalds
2011-11-07 23:21                       ` Alan Cox
2011-11-07 23:27                         ` Greg KH
2011-11-07 23:40                           ` Theodore Tso
2011-11-07 23:45                             ` Alan Cox
2011-11-07 23:45                             ` Greg KH
2011-11-08 20:07                               ` Ted Ts'o [this message]
2011-11-09 16:14                                 ` Greg KH
2011-11-08  9:11                           ` Vasiliy Kulikov
2011-11-08 13:23                             ` Alan Cox
2011-11-08 17:41                               ` Vasiliy Kulikov
2011-11-08 17:06                   ` John Stoffel
2011-11-07 19:54           ` Vasiliy Kulikov
2011-11-07 20:10       ` Valdis.Kletnieks
2011-11-07 20:19         ` Vasiliy Kulikov

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=20111108200735.GM24234@thunk.org \
    --to=tytso@mit.edu \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=eparis@parisplace.org \
    --cc=greg@kroah.com \
    --cc=hpa@zytor.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=segoon@openwall.com \
    --cc=torvalds@linux-foundation.org \
    /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