> I'm trying to impelemnt a lightweight network filesystem and ran into
> trouble implementing lookup, permissions and open.
> The protocol requires me to specify open mode in it's open command. The
> open mode has 4 bits: read, write, append and execute. But I can't tell
> execution from read in file_operations->open. I could send the open command
> from the inode_operations->permission, but this does not solve the problem,
> as I can't find weather to count the new file descriptor as reader or
> executer (I have to know that when closing the file).
The idea of opening files for read and opening files for execution is
bogus and you should fix the protocol, not add more crap to your
There are two ways how you can implement security in network file system:
1. you expect that users have not root access on the client machine and
you check permissions on client (like in NFS). In this case the 'x' and
'r' bits are checked on the client and you don't have to care about them
2. you expect that users have root access on client machine and you check
permissions on the server. In this case users can read executed files
> The server always checks permission on the actual request, so I can't open
> the file for reading, when it should be open for execution.
It seems that you are implementing case 2 of the above.
If you are checking permissions on server, read/execute have no security
meaning. Client can send 'execute' request and then store data somwhere to
file. Opening for 'execute' won't enhance your security.
> 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'.
And also remember that having file without read permission and with
execute permission makes sence only for suid programs. User can read the
file via /proc/<pid>/mem or attach debugger to the process...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/