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.

Re: CIFS improvements/wider testing needed

[Steve French]

Eric,
Thanks for the feedback - any bugs which you report which I can 
reproduce - I will treat
as a very high priority and your testing is helpful.

 > Trying to push Linux in corporate environments in such condition is very
 > difficult because, due to those bugs, you cannot:
 >
 >       1) save a new openoffice document twice,
 >         2) create mail folders from inside thunderbird (local mailbox 
shared
 > with windows),

You can avoid these by mounting with "nobrl" (no remote byte range lock) 
mount option
(smbfs does not send byte range locks so would not run into this 
problem, but would run
into others).    These appear to be byte range locking problems. The 
problem is that cifs has
to map advisory to mandatory locks which only works if the application 
is reasonably well
behaved (not even Samba has support for advisory locks although
they will come with the new Unix extensions). It may be made worse by a 
bug in openoffice
(some Linux apps such as Evolution lock on the "wrong" file handle which 
does not fail in posix,
although is sloppy coding) but I have not confirmed the byte range lock 
sequence which
openoffice is trying as we did with Evolution - I did confirm that nobrl 
(disabling the
byte range locks on the client) works.  Note that this mount option, 
although not listed
as a  bug fix in git per-se - was added to address the evolution etc. 
locking bugs.  There
are quite a few of the cifs changes that fall into that category.

 >         3) avoid to do FSCK after each reboot,
Not sure that cifs would cause this unless you mean that cifs was hung 
and shutdown hung.   To
avoid cases where cifs requests could stay blocked forever (especially 
locking requests),
I added a umount_begin routine a few weeks ago to try to free threads 
blocked in cifs -
but what I need from users/tests if they see a cifs umount fail is to 
know where the requests
are hung so I can add wakeup calls for that condition in
cifs's umount_begin (you can do "echo t > /proc/sysrq-trigger" then 
"dmesg > debugdata" to get
the debugdata which has the callstacks of processes blocked in kernel).

 > I've seen many changes going in CIFS git tree during this period but
 > only few bugs got really hunted and fixed
Scanning the bugzilla list I don't see many which are still believed to 
be valid, but
the bugzilla list for cifs on bugzilla.samba.org needs to be cleaned up.

 >SMBfs do not exibit some of the bugs CIFS has but has other limitations
SMBfs runs far fewer posix applications.   The main advantage smbfs
has is in its kerberos support (which is being worked with the new cifs
upcall) and in that it cheats and opens multiply open files only once and
with the wrong flags (which can help performance in some cases
but the lack of safe caching can lead to data corruption).

 >Could other on the LKML list try to reproduce/confirm the following bugs
 >with the latest snapshot:
That would be very helpful.

 > NB : the second bug appeared with CIFS 1.39 and is not present in 
2.6.14.2
 >
The smb length checking code was fixed in cifs 1.38 or cifs 1.39 (it was 
missing some
illegal cases where tcp length of the smb did not match the calculated 
smb length of
the three parts of the smb).   It of course could be a security exposure to
overly relax the length checking code on incoming
network buffers.  Unfortunately Windows server has at least one bug in which
its server miscalculates the size of an smb with no data area but an
illegal pad but the empty bcc (byte data) area of an SMB - this can 
occur on
byte range locks but we may be seeing a second case in your example. 

 > BUGS :
 >         <https://bugzilla.samba.org/show_bug.cgi?id=2673>
I suspect that this is a difference in default ACLs or share permissions 
on the windows server side, but
as I have mentioned additinal data would be helpful as no one else so 
far has been able to reproduce it
as far as I know.   If that is not the cause it may be a problem with 
the emulation of Linux mode
bits - and of course some three or four of the most recent cifs changes 
have been working case by
case through improving this to Windows servers.  It is not easy code to 
discover and write.

 >         <https://bugzilla.samba.org/show_bug.cgi?id=3237>
I would like to see the debug data ("cat /proc/fs/cifs/DebugData") so I 
can see if there any
pending network requests when your shutdown occurs - and I want to see 
an ethereal trace
(or tcpdump or equivalent binary trace file) of this so I can see what 
is going on with this
malformed response from the server.

 > May I suggest to fix bugs as a priority before adding new features for a
If there is a known bug, reported and which I can recreate - it is of 
course my highest priority
and I would also evaluate patches to fix such as my highest priority - 
but if they are hard
or impossible for me to recreate - getting the very, very, very hot 
issue of Kerberos security
enablement finished is the priority now.

 > Or at least make sure enough testing is done to avoid regressions?
There is a large test suite of the typical Linux fs tests (connectathon 
posix file api,
fsx, fsstress, dbench, etc.) which is run against Samba and Windows on 
every
update of cifs (by me and Shaggy and others who can help from time to time).
I would love additional testing in the user community especially on a 
broader set of servers
than I can test - one person can't possibly have enough servers to test 
every one of the
variations of  Windows servers or even Samba/unix platform variants - 
and there
are dozens of other nas appliances and cifs servers.
 
Although I would like to find a workaround so it does not hang the 
umount or fail umount
I am not convinced that this is a typical regression - if a server sends 
an illegal response which
we were not catching before ... it would be dangerous to call preventing 
that potential
security problem a regression.

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:
> Eric,
> Thanks for the feedback - any bugs which you report which I can
> reproduce - I will treat
> as a very high priority and your testing is helpful.

I know you have tried to reproduce them and failed. The question was how
to go further?

>> Trying to push Linux in corporate environments in such condition is
>> very difficult because, due to those bugs, you cannot:
>> 
>> 1) save a new openoffice document twice, 2) create mail folders
>> from inside thunderbird (local mailbox
> shared
>> with windows),
> 
> You can avoid these by mounting with "nobrl" (no remote byte range
> lock) mount option (smbfs does not send byte range locks so would not
> run into this problem, but would run into others). These appear to be
> byte range locking problems. The problem is that cifs has to map
> advisory to mandatory locks which only works if the application is
> reasonably well behaved (not even Samba has support for advisory
> locks although they will come with the new Unix extensions). It may
> be made worse by a bug in openoffice (some Linux apps such as
> Evolution lock on the "wrong" file handle which does not fail in
> posix, although is sloppy coding) but I have not confirmed the byte
> range lock sequence which openoffice is trying as we did with
> Evolution - I did confirm that nobrl (disabling the byte range locks
> on the client) works. Note that this mount option, although not
> listed as a bug fix in git per-se - was added to address the
> evolution etc. locking bugs. There are quite a few of the cifs
> changes that fall into that category.

Well I would be surprised the "cat >> titi" command does any of this
byte range lock. If the "create and later rewrite the same file"
sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
titi), how can it works with complicated applications?


> 
>> 3) avoid to do FSCK after each reboot,
> Not sure that cifs would cause this unless you mean that cifs was
> hung and shutdown hung. 

Yes : the system hangs when shutting down as the result of the "umount
-a"  with the last message being as described in bug N° 3237. I have to
press power button for 5 seconds.

NB : manually doing the umount does exactly the same things.

> To avoid cases where cifs requests could stay
> blocked forever (especially locking requests), I added a umount_begin
> routine a few weeks ago to try to free threads blocked in cifs - but
> what I need from users/tests if they see a cifs umount fail is to 
> know where the requests are hung so I can add wakeup calls for that
> condition in cifs's umount_begin (you can do "echo t >
> /proc/sysrq-trigger" then "dmesg > debugdata" to get the debugdata
> which has the callstacks of processes blocked in kernel).

Will do that in the bug data.

>> <https://bugzilla.samba.org/show_bug.cgi?id=3237>

> Although I would like to find a workaround so it does not hang the 
> umount or fail umount I am not convinced that this is a typical
> regression - if a server sends an illegal response which we were not
> catching before ... it would be dangerous to call preventing that
> potential security problem a regression.

Hanging a system systematically leading to FSCK on each reboot is not
particularly helpfull given the fact that it happens whebn you are doing
a shutdown in most cases.


-- eric

Re: CIFS improvements/wider testing needed

[Steve French]

VALETTE Eric RD-MAPS-REN wrote:

>Steve French wrote:
>  
>
>>Eric,
>>    
>>
>Well I would be surprised the "cat >> titi" command does any of this
>byte range lock. If the "create and later rewrite the same file"
>sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>titi), how can it works with complicated applications?
>
>  
>
Make sure that you 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)

Re: CIFS improvements/wider testing needed

[VALETTE Eric RD-MAPS-REN]

Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
> 
>> Steve French wrote:
>>  
>>
>>> Eric,
>>>   
>>
>> Well I would be surprised the "cat >> titi" command does any of this
>> byte range lock. If the "create and later rewrite the same file"
>> sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>> titi), how can it works with complicated applications?
>>
>>  
>>
> Make sure that you 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

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