[lkml]   [2004]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC, PATCH] sys_revoke(), just a try. (was: Re: dynamic /dev security hole?)
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.057 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site