On Jun 28, 2008, at 11:45 PM, shailesh jain wrote:
For mmap to succeed, the file should have been opened with the read flag always.
Not at all. A file can be written to without being read, whether the vector by which it is written is a mapped operation or a regular file write.
This is the comment in the mmap code. i.e they implcitly add PROT_READ protection bits. Further down the code they check, if VM_PROT_READ was specified and file was not opened for reading then they return EACCES error code.
You are confusing implementation with design.
There is no reason for you to assume that a mapping will always include PROT_READ, regardless of whether the OS currently has an acknowledged bug that causes it to have to always request it. That behaviour is subject to change at any time.
Yes; there are other ways to map files, just for starters. Also, you are not implementing mmap(2), you are implementing a filesystem. It is an error (as you should have realised from reading the code) to think that your implementation of VNOP_MMAP has much to do with what an application actually sees.
So, if the filesystem is not involved in authorization that what is the purpose of passing protection flag {PROT_WRITE, PROT_READ, PROT_EXEC} to the filesystem ?
These are supplied as a courtesy to the filesystem in case it wants/needs to make specific arrangements regarding the mapping.
I did not follow this comment. What specific arrangements can be made regarding the mapping ?
That's entirely up to you; depending on how your filesystem works, it may or may not be useful for you to know what sort of traffic can be expected against a vnode.
Unless the filesystem is a proxy for a remote authority (e.g. a network filesystem), its responsibility regarding authorisation is limited to correctly answering questions posed by VNOP_GETATTR.
If it was network file system what difference would it make ?
Most network filesystems make file access authorisation decisions on the server.