[lkml]   [2001]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: question: permission checking for network filesystem
> Agree, but it will improve behavior. Or speed, rather. Otherwise open would
> take 3(!) roundtrips (instead of two - now lookup can't be get rid of) -
> lookup, permission and open. The protocol can do all three in one request.
> The problem is I can't tell the 3 calls from VFS belong together.

You can write lookup so that it always succeeds and returns dummy inode
without sending anything and do all the work in open & inode operations.

> > > Could anyone see a solution other than adding a flags to open mode (say
> > > O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec
> > > and sys_uselib? I don't like the idea of pathing vfs for this.
> >
> > Send always 'open for read' and ignore 'open for execute'.
> Won't work for many reasons. Correct error code is one (could be removed by
> pre-checking permission),

> exclusivity of write versus execute is the other
> (can't be workaround).

MAP_DENYWRITE is used for this. If somebody is mapping file with
MAP_DENYWRITE, lock it on server. Write locking does not depend on exec,
and it is bad to expect that it may be used only in exec.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:1.036 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site