Re: [RFC, PATCH] sys_revoke(), just a try. (was: Re: dynamic /dev security hole?)

[Albert Cahalan <albert@users.sf.net>]

On Thu, 2004-08-12 at 15:51, Alan Cox wrote:
> 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
> 
> > +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.

Two other choices:

a. map anon memory over the old mapping
b. fail the revoke() call, perhaps with EBUSY

> A second is that 
> while you can ->flush() here you can't really close it until the
> file usage count hits zero. 
> 
> You are btw tackling a really really hard problem and its more likely
> 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.

What about using a signal with enforced action?
(like SIGSTOP and SIGKILL) The user could still
install a handler, but only to know when revoke()
has taken action. I have a feeling that this would
be less trouble, since the losing process performs
action on its own data structures.

BTW, one must watch out for dup2() in another thread.