Re: question: permission checking for network filesystem

[Mikulas Patocka]

> 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. 

Mikulas