Björn Steinbrink wrote: > > On 2006.07.20 23:02:53 +0300, Kari Hurtta wrote: > > Pekka J Enberg <penberg@xxxxxxxxxxxxxx> writes in > > gmane.linux.file-systems,gmane.linux.kernel: > > > > > From: Pekka Enberg <penberg@xxxxxxxxxxxxxx> > > > > > > [...] > > > After we have done that to all file descriptors, we close the files and > > > take down mmaps. > > > > What permissions is needed revoke access of other users open > > files ? > > [...] > > BSD manual page for revoke(2) seems say: > > > > Access to a file may be revoked only by its owner or the super user. > > In do_revoke() there is: > > + if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER)) { > + ret = -EPERM; > + goto out; > > That pretty much matches what the BSD manpage says. Urgs, so any user may remove mappings from another process and let it crash? Reading revoke man pages, it seems the system call was meant for tty devices. While I can see the generic case to be useful for forced unmount, it seems pretty dangerous to allow any user to revoke file access and tear down mappings. Who needs the generic case anyway? IMO that's too much rope. The effect on affected processes is nearly unpredictable. IMHO, fuser is "good enough(tm)". Btw, grep revoke POSIX.txt -> nil. Ciao, ET. - 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