Messages in this thread | | | Subject | Re: [RFC, PATCH] sys_revoke(), just a try. (was: Re: dynamic /dev security hole?) | From | Albert Cahalan <> | Date | 12 Aug 2004 15:39:32 -0400 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |