question: permission checking for network filesystem

question: permission checking for network filesystem

[Jan Hudec]

Hi,

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 server always checks permission on the actual request, so I can't open
the file for reading, when it should be open for execution.

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.

If it has to be patched, what kind of patch has a chance to get into 2.4
series kernel?

There is another thing with lookup. The protocol allows looking up and
opening a file in one command. Unfortunately there are some file-type
checks between i_ops->lookup and f_ops->open that force me to wait on the
lookup to finish before I can open. I think these checks could be done by
simply having the f_ops->open set correctly (thinks like not opening
directory for write). But I do not expect these to change before 2.5,
right?

Thanks in advance.

Bulb

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

Re: question: permission checking for network filesystem

[Mikulas Patocka]

Hi

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

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

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

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

Mikulas

Re: question: permission checking for network filesystem

[David Wagner]

Mikulas Patocka  wrote:
>If you are checking permissions on server, read/execute have no security
>meaning.

This seems a bit too strong.  If I try to exec a file that has read
permission enabled but not execute permission, I'd like this to fail.
You can just imagine sysadmins who turn off exec bits on old buggy apps
to prevent users from executing them, who could get bit in the butt by
the sort of unexpected behavior that would result from ignoring execute
permission bits.

Re: question: permission checking for network filesystem

[Jan Hudec]

Hi,

> > 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
> 
> 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
> in protocol. 
> 
> 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
> anyway.

Neither. If user has acces to the protocol, he certainly can do some things
more. But you definitely can't check permissions on client. The trouble is,
that this limits access policy on server to what the clients understand.
Checking on server on the other hand allows server to implement any access
policy (even using 3rd party software) without having clients to know the
details (sou they can be kept stupid and simple = fast and managable)

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

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.

> > 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). Checking permissions with lookup might be possible,
but won't solve the exec/write exclusion and put more trust on the client,
than is desireable.

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

It does not make sence (x without r). But it surely makes sence to have a
program with read but without exec permission (though it can be made to
run).

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

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

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' <bulb@ucw.cz>

Re: question: permission checking for network filesystem

[Jan Hudec]

> > open mode has 4 bits: read, write, append and execute.
> 
> I hope "write" and "append" interact nicely, giving 4 choices.
> 
> 00 no write
> 01 append only
> 10 overwrite only (no file size change)
> 11 full write, append, truncate, etc.

... that's 1) Wrong 2) I need 4 bits ... that's 16 choices.

It's wrong because append is specified in addition to write (for open syscall).

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>