CIFS Unix Extensions UIDs and client permission checking

[Steve French]

Network filesystems such as cifs clients have three loosely related 
security issues that are harder to handle than the local filesystem case:
- setting the default uid/gid on mkdir/create/mknod
- reporting uid/gid on lookup
- whether the client should do permission checking (check the effective 
uid vs. the unix mode)

When CIFS Unix Extensions are not enabled on the server:
1) should the Linux cifs client do standard Unix perm checking using the 
current effective uid/gid against the default mode/mask passed in on the 
mode.    (note that the server obviously does a different perm checking 
already but with the identity of the user who mounted against the server 
side acl)

My current thinking is that client perm checking should be on by 
default, but could be disabled with a mount parm (can not disable though 
when the mount helper is run setuid).

2) what should the default uid/gid be?  Now the default uid/gid is taken 
from the "uid=" and "gid=" mount parms if they are passed on mount, and 
if they are not passed the default uid/gid reported on lookup by the 
client is current->uid and current->gid

When CIFS Unix extensions are enabled the case is more complicated:
1) What UID/GID should be used when doing create/mkdir/mknod (the 
effective uid of the client process, or let the server use the uid of 
the user from the mount)?  

My current thinking is that the UID/GID should be the default ie the 
client sends -1 as the UID (ie whatever the server sets, probably the 
server's UID for the user who mounted), unless overridden by a mount 
parm.  When the client thinks that the UIDs/GIDs on the server and 
client match allowing a mount parm to control this will help get closer 
to local behavior.   The client can attempt to explicitly change the UID 
via chown though.  

2) Should the client do standard Unix perm checking against the server 
reported mode/uid/gid of the file (since only the client knows the 
effective uid/gid of the current process) ?

My current thinking is that the client should do client side perm 
checking unless it is disabled via a mount parm (can not disable when 
the mount helper run setuid) or eventually when "MultiuserMount" 
configuration setting (/proc/fs/cifs) is enabled (and the code for 
MultiuserMount is complete).  This is a change from what the client does 
now (where it only does perm checking when Unix extensions are not 
negotiated).    The intent of MultiuserMount is eventually to allow the 
client to be configured to do additional SMB session setups for each 
distinct UID who attempt to access the mount so we can pass the right 
SMB uid/tid on path based requests to the server.

3) Are there any cases in which the uid/gid reported on lookup (from the 
server in response to Unix trans2 QPathInfo requests) should be 
overridden on the client?

I couldn't think of any


Does this logic seem correct?  Obviously this could be improved somewhat 
if the CIFS Unix/Linux extensions are extended - e.g. we optionally 
could pass the client process's effective uid/gid to the server (so the 
server had all of the info it needed to do the real permission check) 
and if the server trusted the client and if signing were enabled (so the 
uid/gid could not be changed on the wire by a man in the middle).

Any suggestions for the name of the two proposed cifs mount parms e.g.l

Also - jra had talked about an interesting idea for a pipe based helper 
mechanism that might assist with the uid translation.