public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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-----

  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