From: Michael Buesch <mbuesch@freenet.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Albert Cahalan <albert@users.sourceforge.net>,
Eric Lammerts <eric@lammerts.org>,
Marc Ballarin <Ballarin.Marc@gmx.de>, Greg KH <greg@kroah.com>
Subject: Re: [RFC, PATCH] sys_revoke(), just a try. (was: Re: dynamic /dev security hole?)
Date: Fri, 13 Aug 2004 14:39:11 +0200 [thread overview]
Message-ID: <200408131439.19704.mbuesch@freenet.de> (raw)
In-Reply-To: <1092340279.22362.6.camel@localhost.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoting Alan Cox <alan@lxorguk.ukuu.org.uk>:
> On Iau, 2004-08-12 at 17:49, Michael Buesch wrote:
> > +static ssize_t revoke_read(struct file *filp,
> > + char *buf,
> > + size_t count,
> > + loff_t *ppos)
> > +{
> > + return 0;
> > +}
>
> -EIO I think but I'm not sure I remember the BSD behaviour in full
[SNIP]
REVOKE(2) OpenBSD Programmer's Manual REVOKE(2)
NAME
revoke - revoke file access
SYNOPSIS
#include <unistd.h>
int
revoke(const char *path);
DESCRIPTION
The revoke function invalidates all current open file descriptors in the
system for the file named by path. Subsequent operations on any such de-
scriptors 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() 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 refer-
ences to the file had been close
[SNAP]
Means, that it returns different values for normal files and device
files? Do I understand that correctly?
- -EIO for files
0 for device nodes
> > +static int filp_revoke(struct file *filp, struct inode *inode)
> > +{
>
> First problem here is that the handle might still be in use
> for mmap, so you'd need to undo mmaps on it. A second is that
So I guess if we simply munmap them, programs will fail (will
segfault?). Or is it safe to munmap a mapping, while some
program is using it?
> while you can ->flush() here you can't really close it until the
> file usage count hits zero.
Is it really required to close it in revoke? I mean, if we flush it,
no data remains unwritten to disk. The user program will call
close, later by itself.
> You are btw tackling a really really hard problem and its more likely
Yes, yes. I know. ;)
> the way to do this is to add revoke() methods to drivers and do it at
> the driver level - as the tty layer does with vhangup.
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBHLZ1FGK1OIvVOP4RAsXCAKCacyQvhemTY3CU47IwRBRxkBJYOwCguHq6
uKebhV87/GyDIJT5hk+0tbk=
=sIL3
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-08-13 12:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-08 12:47 dynamic /dev security hole? Albert Cahalan
2004-08-08 15:58 ` Marc Ballarin
2004-08-08 15:04 ` Albert Cahalan
2004-08-08 20:42 ` Greg KH
2004-08-08 16:21 ` Greg KH
2004-08-08 21:43 ` Marc Ballarin
2004-08-08 22:07 ` Marc Ballarin
2004-08-09 4:40 ` Eric Lammerts
2004-08-09 13:30 ` Michael Buesch
2004-08-09 13:19 ` Albert Cahalan
2004-08-09 16:54 ` Michael Buesch
2004-08-09 17:04 ` Eric Lammerts
2004-08-09 17:14 ` Michael Buesch
2004-08-10 0:21 ` Greg KH
2004-08-11 17:12 ` [RFC, PATCH] sys_revoke(), just a try. (was: Re: dynamic /dev security hole?) Michael Buesch
2004-08-12 16:49 ` Michael Buesch
2004-08-12 19:51 ` Alan Cox
2004-08-12 19:39 ` Albert Cahalan
2004-08-13 12:39 ` Michael Buesch [this message]
2004-08-09 14:49 ` dynamic /dev security hole? Alan Cox
2004-08-09 16:17 ` Eric Lammerts
2004-08-09 15:33 ` Alan Cox
2004-08-09 16:47 ` Eric Lammerts
2004-08-09 17:54 ` Alan Cox
2004-08-10 0:21 ` Greg KH
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=200408131439.19704.mbuesch@freenet.de \
--to=mbuesch@freenet.de \
--cc=Ballarin.Marc@gmx.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albert@users.sourceforge.net \
--cc=eric@lammerts.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.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