CIFS emulated mode bits

CIFS emulated mode bits

[Steve French]

VALETTE Eric RD-MAPS-REN wrote:

>Steve French wrote:
>  
>
>>VALETTE Eric RD-MAPS-REN wrote:
>>
>>    
>>
>>>Steve French wrote:
>>>      
>>>
>>let me know if your cat example works when mounted
>>with the relatively new "noperm" mount option on the client.   At least
>>then we will know whether we are looking at a problem with access
>>control on the server (ntfs acls) or client (unix mode bits and the
>>.permission entry point)
>>    
>>
>
>Works with the "noperm" mount option.
>
>--eric
>
>  
>
OK - That is good, should be relatively easy to debug from here.

To explain what is going on, here is some obvious background.    Windows 
uses a rich ACL model locally and over the network via CIFS (other 
protocols such as NFSv4 now do something similar) and Windows of course 
does not have really have or need Unix mode bits ... and the server 
(unlike Samba and those that implement the standard SNIA CIFS Unix 
extensions) does not return emulated mode bits (although it does locally 
in Windows "services for Unix" and of course also cygwin does something 
similar) ... so the cifs  client has to approximate mode bits.    If the 
client makes an incorrect approximation you can get access denied on a 
client side permission check.   Of course some would argue that for 
clients that are running as single user desktop clients the client does 
not need to do perm checks (the server does ACL checks) so just turn off 
the client permission checks - that is why the "noperm" option is 
available on the cifs client.

So the choices today are:

1) Turn off mode bit checking (on the client) on a particular cifs mount 
(noperm mount option)
or
2) pass in a default mode and uid or gid on the cifs mount that matches 
what you want (otherwise cifs will use the uid of the mounter, and a 
default mode).  Although cifs caches the mode bits in the inode if they 
are modified by an app on the client e.g. via chmod (while the inode 
stays in memory on the client) - for querying (lookups/stat) on existing 
files cifs can only use the +R dos attribute to distinguish when to 
return something other than 0777 (or the default).
or
3) turn on the "sfu" mount option on the client and let cifs make the 
(more expensive) queries to the server for mode information the same way 
that "services for unix" would.   This does not work for all mode bits 
yet, as it requires additional CIFS ACL support to be coded, but it does 
now work for the 3 bits above 0777 (as of just after 2.6.15-rc2).

Following the suggestions of Martin Koeppe and others there may be a 
need to allow a "cygwin" mount option as well.

CIFS emulated mode bits

[Steve French]

VALETTE Eric RD-MAPS-REN wrote:

> Steve French wrote:
>  
>
>> VALETTE Eric RD-MAPS-REN wrote:
>>
>>   
>>
>>> Steve French wrote:
>>>     
>>
>> let me know if your cat example works when mounted
>> with the relatively new "noperm" mount option on the client.   At least
>> then we will know whether we are looking at a problem with access
>> control on the server (ntfs acls) or client (unix mode bits and the
>> .permission entry point)
>>   
>
>
> Works with the "noperm" mount option.
>
> --eric
>
>  
>
OK - That is good, should be relatively easy to debug from here.

To explain what is going on, here is some obvious background.    Windows 
uses a rich ACL model locally and over the network via CIFS (other 
protocols such as NFSv4 now do something similar) and Windows of course 
does not have really have or need Unix mode bits ... and the server 
(unlike Samba and those that implement the standard SNIA CIFS Unix 
extensions) does not return emulated mode bits (although it does locally 
in Windows "services for Unix" and of course also cygwin does something 
similar) ... so the cifs  client has to approximate mode bits.    If the 
client makes an incorrect approximation you can get access denied on a 
client side permission check.   Of course some would argue that for 
clients that are running as single user desktop clients the client does 
not need to do perm checks (the server does ACL checks) so just turn off 
the client permission checks - that is why the "noperm" option is 
available on the cifs client.

So the choices today are:

1) Turn off mode bit checking (on the client) on a particular cifs mount 
(noperm mount option)
or
2) pass in a default mode and uid or gid on the cifs mount that matches 
what you want (otherwise cifs will use the uid of the mounter, and a 
default mode).  Although cifs caches the mode bits in the inode if they 
are modified by an app on the client e.g. via chmod (while the inode 
stays in memory on the client) - for querying (lookups/stat) on existing 
files cifs can only use the +R dos attribute to distinguish when to 
return something other than 0777 (or the default).
or
3) turn on the "sfu" mount option on the client and let cifs make the 
(more expensive) queries to the server for mode information the same way 
that "services for unix" would.   This does not work for all mode bits 
yet, as it requires additional CIFS ACL support to be coded, but it does 
now work for the 3 bits above 0777 (as of just after 2.6.15-rc2).

Following the suggestions of Martin Koeppe and others there may be a 
need to allow a "cygwin" mount option as well.

Re: CIFS emulated mode bits

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:

> To explain what is going on, here is some obvious background.    Windows
> uses a rich ACL model locally and over the network via CIFS (other
> protocols such as NFSv4 now do something similar) and Windows of course
> does not have really have or need Unix mode bits ... and the server
> (unlike Samba and those that implement the standard SNIA CIFS Unix
> extensions) does not return emulated mode bits (although it does locally
> in Windows "services for Unix" and of course also cygwin does something
> similar) ... so the cifs  client has to approximate mode bits.    If the
> client makes an incorrect approximation you can get access denied on a
> client side permission check.   Of course some would argue that for
> clients that are running as single user desktop clients the client does
> not need to do perm checks (the server does ACL checks) so just turn off
> the client permission checks - that is why the "noperm" option is
> available on the cifs client.
> 
> So the choices today are:
> 
> 1) Turn off mode bit checking (on the client) on a particular cifs mount
> (noperm mount option)

I could live with that altthough there is something I would like to
clarify (see below).

> or
> 2) pass in a default mode and uid or gid on the cifs mount that matches
> what you want (otherwise cifs will use the uid of the mounter, and a
> default mode).  Although cifs caches the mode bits in the inode if they
> are modified by an app on the client e.g. via chmod (while the inode
> stays in memory on the client) - for querying (lookups/stat) on existing
> files cifs can only use the +R dos attribute to distinguish when to
> return something other than 0777 (or the default).

If you put something is a /etc/fstab, that will be mounted by init
scripts, the uid/gid credentials attached with the mount request is of
course root.root (which is wht is see with "ls file" BTW). 'I'm just
surprised that with the perm option, my identity seems to change, on the
client side, between the two commands : if the file is marked locally as
created by root.root, I should still be root.root for the next command!

Side question for my understanding : when I specify  the credentials
(like I did) (credentials=/home/ceva6380/.sambaShareId) and that the
user name exist in the local /etc/passwd, I'm surprised to have to add
the uid=getuidfrom(name) again. I admit, user name on the windows server
may be different than on the client, but to put a valid uid/gid it must
exist on the client system anyway and be consistent with the current
user identity no?


-- eric