[linux-cifs-client] Re: linux-cifs-client Digest, Vol 36, Issue 14

Steve French (smfltc) smfltc at us.ibm.com
Sat Nov 25 16:49:19 GMT 2006

On Wed, 2006-11-22 at 18:32 -0800, ext Linux Lover wrote:

>I just tried "mount -t cifs" (for the first time)
>instead of "mount -t smbfs" that I usually use - all
>other parameters in the mount command identical.
>I was surprised to discover that instead of getting
>the access control dictated by the smb.conf on the
>server side (as in SMBFS), CIFS would pass the native
>permissions on that Linux based Samba server.
>I am pretty sure this difference is by design, but
>since my userid's uid in the client system is
>different than the one in the server side, I cannot
>access key directories in the share...
>Which lets me access that share as if I were on a
>Windows machine.
>>For example, if on the server side I have:
>>drwxr-x---  42 lynn lynn 4096 Nov 14 23:55 data
>>mounting it via CIFS, I get on the client:
>>drwxr-x--- 42 500 500    0 2006-11-14 23:55 data
>>but mounting it SMBFS, I get on the client
>>drwxrwxrwx 1 root root    0 2006-11-14 23:55 data
>>Which lets me access that share as if I were on a
>>Windows machine.
>>Any idea how to workaround this? That is, still use
>>CIFS but not restrict access to the user who
>>successfully mounted that share (using sudo)?
>Sounds what you want to do is use security=share in the global section
>of your samba configuration. man smb.conf for (much) more details.
>Another possibility would be to use the uid=lynn option to mount.cifs.
>man mount.cifs for further details.
>David Juran
>Sr. Consultant
>Red Hat
I don't think that using share level security would be necessary here.   
The easiest solution is
to simply turn off the CIFS Unix Extensions on the client.

The following information is very important to understand when the 
server and client machines are not
in the same domain (ie not running winbind or equivalent) ... there are 
two configuration issues to understand:

1) Where are authorization checks (user against the mode or ACL) performed?
    a) on the client AND server (default)
    b) only on the server (mount option "noperm" disables the client 
side permission check)
2) What UID/GID/mode will the client report which is controlled by 
whether the
Unix extensions (recently extended and called CIFS POSIX Extensions) are 
enabled on the
client and server.  When Unix Extensions are enabled, the client reports 
the uid/gid/mode that the server sends
(so in that case the "uid=" and "gid=" and "file_mode" mount options are 
meaningless).   When the server uids/gids
are different than the client's uids/gids, there is not much point in 
displaying the server's view of the mode either.  So
there are a few ways of turning this off, on the client or on the 
server.   Unix Extensions are disabled on the server
via smb.conf (for Samba).   Windows does not support the Unix Extensions 
so it is not an issue for mounts to them.
The Unix Extensions can be disabled on the client by setting "echo 0 > 
before the mount (and can be reenabled for subsequent mounts by "echo 1 
 > /proc/fs/cifs/LinuxExtensionsEnabled")
Unix Extensions are negotiated at mount time.  It is usually easiest to 
disable the Unix Extensions on the client
in the case you described (in which the uids/gids differ between client 
and server) or to run a nss module on
the client and server (such as winbind) to make sure that the uids/gids 
are the same.

In some cases it is also helpful to understand a third item:
3) Which user identifier ("smb uid", somewhat similar to credentials) do 
we send to the
server on a particular request to open/create a file
    a) the one we used to mount with (default) or
    b) the one which matches the uid of the current process (if we have 
mounted more than once to the
same server from the same client with different uids and usernames).  
This is enabled by setting the
mount option "MultiuserMount" to 1.

-------------- next part --------------
HTML attachment scrubbed and removed

More information about the linux-cifs-client mailing list