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@xxxxxxxxxxxxxx> > > > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
