[linux-cifs-client] Re: No legacy mount possible at all ANYMORE? - the kernel option CONFIG_CIFS_WEAK_PW_HASH

Guenter Kukkukk linux at kukkukk.com
Sat Mar 15 17:09:20 GMT 2008


Am Samstag, 15. März 2008 schrieb Steve Langasek:
> Hi Guenter,
> 
> On Sat, Mar 15, 2008 at 05:33:24AM +0100, Guenter Kukkukk wrote:
> > if (smbfs_has_been_removed && kernel_has_been_build_without_CONFIG_CIFS_WEAK_PW_HASH) {
> >      printf ("Sorry, 2008 - you cannot mount ANY legacy server anymore!\n");
> > }
> 
> >  - the kernel module smbfs.ko will be removed very soon.
> >  - also the (original!!!) samba userland helpers smbmount,
> >    smbmnt and smbumount
> 
> > The daily answer "just mount cifs" is _critical_ regarding
> > legacy servers like win9x/me, os/2, dos, ...
> 
> > WHY:
> > ====
> > Even if cifs vfs would support all features of smbfs -
> > which is NOT the case - there's is a REAL problem NOW:
> 
> >    if the todays or future kernels are _not_ build with
> >    CONFIG_CIFS_WEAK_PW_HASH, then _all_ legacy support
> >    just has _gone_ !
> 
> > Any _new_ legacy additions to cifs vfs would be worthless,
> > cause the _mount_ would not succeed at all.
> 
> Thanks for pointing this out.  I've filed a bug report with the Ubuntu
> kernel team requesting that this option be enabled for the upcoming 8.04
> release, and it should also be enabled in an upcoming Debian kernel upload.
> sho
> > The new debian/ubuntu re-written "faking" smbmount and smbumount
> > do not help at all - to me, that's "silly nonsense" - sorry!
> 
> That's your opinion (and not a very constructive approach).  The mapping of
> smbfs to cifs is being done to provide as smooth as possible of a
> transition for users currently using the smbfs driver.  I'm confident that
> 99% of the users still using smbmount on Debian or Ubuntu are doing so with
> servers that are supported by cifs.  For those that aren't, there is no
> smooth transition possible with or without a wrapper; for everyone else,
> anything that we fail to map in mount.smbfs is a bug that we can and should
> fix.
I apologize for having been a bit rude here - sorry!
I wrote all this down after a long night on irc and hunting a smbclient bug.
Was very tired and unconcentrated ...
I guess, most of todays users are using cifs vfs with the basic userland helpers
mount.cifs and umount.cifs.
Only a few are still using smbmount and smbumount - but they _associate_ both
"with mounting/unmounting smbfs" - and so expect to _really_ mount/umount smbfs.
Mounting cifs vfs now "behind the scenes" instead will add a lot of confusion - talks
on irc channel #samba document this.
I vote, to just drop them, to make it very clear that smbfs is no longer
available and user interaction is needed.
Such wrappers would be fine in the case were cifs vfs could easily replace 
smbfs (same feature set) - but today cifs is missing many legacy features.

> 
> > WHAT CAN BE DONE?:
> >  - leaving smbfs (and related stuff) in place
> 
> I don't think either Debian or Ubuntu (or upstream) want to do this. The
> smbfs driver and userspace tools both have numerous issues that will never
> be worked on; it's not reasonable to expect this driver to be supported
> indefinitely.
> 
> >  - inform all distro maintainers about this
> >  - drop legacy mount support completely (!?)
> 
> If you mean dropping this support from the cifs driver, that doesn't make
> any sense at all.  *No one* is supporting the smbfs driver; it has
> significant bugs that are never going to be worked on, and based on the bug
> reports I've seen over the years in Debian, I think it's even suffered from
> some pretty hefty bit rot in the kernel.
> 
> It would be a shame to have the cifs maintainers deny support for legacy SMB
> servers.  It's clear to me that even if cifs doesn't yet support all servers
> perfectly, *users* are getting much better support for problems with cifs
> than they have in years for smbfs.
> 
> >  - build 2 versions of cifs vfs
> >    - one without CONFIG_CIFS_WEAK_PW_HASH
> >    - one with CONFIG_CIFS_WEAK_PW_HASH
> 
> Why?  LANMAN and plaintext are still disabled by default at runtime when
> CONFIG_CIFS_WEAK_PW_HASH is enabled.  I can't see any reason to build *two*
> copies of cifs.ko when this is perfectly selectable at runtime.
> 
> So I think the best option is really:
> 
>   - enable CONFIG_CIFS_WEAK_PW_HASH by default upstream

I also think, that this is the best solution!  :-)

In addition cifs can also "be adjusted" by setting flags in
/proc/fs/cifs/SecurityFlags - this has already been implemented.

Cheers, Günter


More information about the linux-cifs-client mailing list