Re: + deprecate-smbfs-in-favour-of-cifs.patch added to -mm tree
Posted May 18, 2006 21:00 UTC (Thu) by stevef
Parent article: Re: + deprecate-smbfs-in-favour-of-cifs.patch added to -mm tree
The uid issue mentioned was probably not a problem - cifs supports it on mount. Note that the Windows95 and OS/2 backlevel support is pretty close (lanman auth works) although not quite ready for mm yet.
Here was the note I had sent Dave which gives more detail on cifs handling of uids:
I am not aware of a problem with uid/gid mount options, there is more detail in fs/cifs/README in the section on "CIFS VFS Mount Options" under uid/gid but let me know if you see something missing there. I wonder if this is something related to an older mount.cifs only accepting numeric uids?
Basically if the server (e.g. Windows or NetApp or EMC) does not support the CIFS Unix Extensions (an optional protocol extension which Samba, HP and a few other server support) then the default uid and gid for all files/directories on the mount can be set by passing
uid=<name or number>
similarly for gid. The support for handling uid (or gid) as a username (instead of the uid number itself) has been in mount.cifs.c for quite a while, but probably less than a year.
If the server (like Samba) does support Unix extensions, the uids/gids will be reported as whatever the server says - if that behavior is not desired, the user should turn off the Unix Extensions on the client (or server)
e.g. "echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled"
I don't mind extending this (default uid/gid behavior) to add more features if you see something obvious (differences in defaults for directories/files etc.). I have been thinking that both NFSv4 and CIFS need a way to remap uids on the client in a more flexible way (as some nfs v3 servers used to allow) - to allow for cases where the server and client uids do not match (and where one default uid for the whole mount is not good enough).
I wish we could disable smbfs faster as well (I get a few questions a month on it) but the two obstacles that I see most often are:
1) Lack of Kerberos (and ntlmv2) support in cifs. As cifs does not (yet) use an upcall to samba for "extended security" flavors of session setup (as smbfs does, albeit in an awkward way) Kerberos support is still most likely a few months away, although ntlvm2 support (which although less well known is good enough for certain government and enterprise security requirements) is missing very little code and could be finished sooner. Part of the obstacle to the cifs upcall for kerberos (and dfs support too) has been the lack of an example for the new cn.ko (connector up call) which would be reusable - as the Samba code that I need to invoke is essentially done
2) Very backlevel server support (mainly allowing very weak lanman passwords, os/2 and windows 95 session setup, and support for mapping Linux time to/from 2 second dos time). I am about halfway through the backlevel sessionsetup (lanman style) support - for obvious security reasons this support would have to be explicitly turned on in /proc/fs/cifs or as mount parm (to allow weak passwords to flow on the wire) and probably be turned off in some menuconfig as well so users don't attempt to mount with weak passwords unless they know what they are doing
to post comments)