Messages in this thread | | | Date | Tue, 22 May 2001 10:10:07 +0200 | From | Jan Hudec <> | Subject | Re: question: permission checking for network filesystem |
| |
> 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' <bulb@ucw.cz> - 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/
| |