[linux-cifs-client] Re: smbfs vs cifs with permissions

[Steven French]

> I've looked at some tethereal traces when connecting with both cifs and 
> smbfs, and I have a theory:  when I connect with smbfs, and say 
> username=user/host, in the SMB session setup trace it has:
>                User: HOST\user
> however when I do the same with cifs, it has:
>                User: \host\user

The uppercase version would normally be the correct one - I normally 
expect the domain (or workgroup) to be specified in that field, but you 
are putting the server's hostname which is a little unusual but probably 
should work as long as there is a local Windows user defintion for "user" 
on that server system.   If there is no local definition for user on that 
server then this might result in checking for a trusted domain with that 
name so it is safer to not specify the domain name (or in your case 
servername) at all so null gets put in that field on the wire which is 
much safer - since that unambiguously asks the server to check its local 
user accounts repository to validate the user.

> Looking at the two traces, in the smbfs case the capabilities field has 
> fewer bits set, notably the unicode bit is clear. 

Yes - that is expected for this older version of the smbmount that you are 
using, which results in among other things the user and the domain being 
passed in Unicode (which is normally preferable).  I doubt that this is 
related to your problem. 

> The smbfs transmit both  an ANSI and UNICODE version of the password. By 
contrast 
> in the cifs case only a UNICODE password is transmitted.

That is an interesting point - this can break some passthrough security 
environments but is better to fail than send the weak lanman hashed 
challenge IMO.   The "ASCII version of the password" (actually the lanman 
hash of the challenge with the ASCII password) is very insecure with 
modern computers attacking it.   In the cifs vfs I had code that could 
send it originally but I disabled the code that computes and sends this 
since it is so easy to break.  Sending both - a weak and a stronger 
("Unicode" ie NTLM) password hash in the same request seems dangerous at 
best, so I only send the relatively stronger NTLM hash.   I consider this 
a security exposure in some clients (that they can easily expose such a 
weak password). 

Let me know if sending no domain (server) worked, and if the user is 
created as a local user in the target system.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-------------- next part --------------
HTML attachment scrubbed and removed