lkml.org 
[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?)
From
Date
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/

\
 
 \ /
  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