Re: question: permission checking for network filesystem

[Jan Hudec]

> 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.
 
It'd be great if I could. But I can't. First, the inode data are checked by
some vfs functions before driver is called (this being the bigest problem:
if (S_ISDIR(inode->i_mode) && (flag & FMODE_WRITE)) goto exit;
- I think these checks could be, perhaps better, done by having right
i_fop->open on different types of inodes)

It could be done partialy (ie. returning dummy data for all but the last
inode in path_walk) if path_walk passed LOOKUP_CONTINUE to i_ops->lookup
(it's passed to d_ops->d_revalidate so NFS can avoid revalidating inodes on
the way). I think adding this flag to i_ops->lookup won't break anything
and make path_walk more self-consistent. (Also passing all flags from
path_walk might help some optimization).

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

There is one problem - I don't get to get/deny_write_permission functions.
They operate on i_writecount and don't call the driver. MAP_DENYWRITE must
be solved by mandatory write-lock on the file... I still think it's better
to check permission in open (

Anyway, is there any reason file->f_ops->open shouldn't have the
information inode->i_ops->permission had? Even if I unite opening for read
and for exec, permissions still have to be queried and permission is
definitely no good place. Lookup might do, but it might not do on other
operating systems.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <[e-mail]>