[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4BA97845-BA47-47F3-A923-9B24AB7306E9@mit.edu>
Date: Mon, 7 Nov 2011 18:40:13 -0500
From: Theodore Tso <tytso@....EDU>
To: Greg KH <greg@...ah.com>
Cc: Theodore Tso <tytso@....edu>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
Vasiliy Kulikov <segoon@...nwall.com>,
Eric Paris <eparis@...isplace.org>,
kernel-hardening@...ts.openwall.com, Valdis.Kletnieks@...edu,
linux-kernel@...r.kernel.org,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-security-module@...r.kernel.org
Subject: Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts
On Nov 7, 2011, at 6:27 PM, Greg KH wrote:
>
> So, what do we really need revoke() for these days?
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.
> But that's getting away from the original topic here, sorry…
Yup. But if revoke has come up, I'd like to remind folks that there are good uses of it besides just tty devices that receive hangup events. Having the modem connection disappear and the USB device disappear isn't all that different from a conceptual point of view.
-- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists