CIFS Unix Extensions UIDs and client permission checking
smfrench at austin.rr.com
Sat Jul 17 16:40:08 GMT 2004
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
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.
More information about the samba-technical