Re: [RFC/PATCH 2/5] revoke: core code

[Al Viro <viro@ftp.linux.org.uk>]

On Wed, Jul 11, 2007 at 10:37:33AM +0100, Al Viro wrote:
> On Wed, Jul 11, 2007 at 12:01:06PM +0300, Pekka J Enberg wrote:
> > From: Pekka Enberg <penberg@cs.helsinki.fi>
> > 
> > The revokeat(2) and frevoke(2) system calls invalidate open file descriptors
> > and shared mappings of an inode.  After an successful revocation, operations
> > on file descriptors fail with the EBADF or ENXIO error code for regular and
> > device files, respectively.  Attempting to read from or write to a revoked
> > mapping causes SIGBUS.
> > 
> > The actual operation is done in two passes:
> > 
> >  1. Revoke all file descriptors that point to the given inode. We do
> >     this under tasklist_lock so that after this pass, we don't need
> >     to worry about racing with close(2) or dup(2).
> 
> How does that deal with the following:
> 
> task A gets its descriptor table cleansed
> task B sends a descriptor to task A via SCM_RIGHTS datagram
> task B gets its descriptor table cleansed
> task A receives the datagram and gets the descriptor installed
> task A does any kind of IO on that descriptor
> ->f_mapping gets replaced in the most inconvenient time.
> 
> Come to think of that, what do you do if I create a socketpair,
> stuff the descriptor into SCM_RIGHTS datagram and send it to
> myself?  Then receive it a day after you've called revoke() and
> voila - I've got an almost undamaged struct file back...  At
> the very least, it allows me to fchmod().  Or fchdir() if that
> had been a directory...
> 
> BTW, read() or write() in progress might get rather unhappy if your
> live replacement of ->f_mapping races with them...

Better: I have the only opened descriptor for foo.  I send it to myself
as described above.  I close it.  revoke() is called, finds no opened
instances of foo in any descriptor tables and cheerfully does nothing.
I call recvmsg() and I have completely undamaged opened file back.