lkml.org 
[lkml]   [2006]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH] revoke/frevoke system calls
Björn Steinbrink wrote:
>
> On 2006.07.20 23:02:53 +0300, Kari Hurtta wrote:
> > Pekka J Enberg <penberg@cs.Helsinki.FI> writes in
> > gmane.linux.file-systems,gmane.linux.kernel:
> >
> > > From: Pekka Enberg <penberg@cs.helsinki.fi>
> > >
> > > [...]
> > > 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-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: 2006-07-22 00:19    [W:0.086 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site