linux-kernel - Re: [2.6.27 patch] the scheduled smbfs removal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 May 2008 20:49:49 -0500
From:	"Steve French" <smfrench@...il.com>
To:	"Harvey Harrison" <harvey.harrison@...il.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Adrian Bunk" <bunk@...nel.org>, linux-kernel@...r.kernel.org,
	"Günter Kukkukk" <linux@...kukk.com>,
	samba-technical@...ts.samba.org, linux-cifs-client@...ts.samba.org
Subject: Re: [2.6.27 patch] the scheduled smbfs removal

On Mon, May 19, 2008 at 7:49 PM, Harvey Harrison
<harvey.harrison@...il.com> wrote:
> On Mon, 2008-05-19 at 19:00 -0500, Steve French wrote:
>> Harvey Harrison <harvey.harrison@...il.com> wrote on 05/19/2008
>> Note that some of the backlevel server support issues aren't handled
>> by smbfs either (and are hard due to protocol limitations). Guenter
>> Kukkukk had been tracking some of the issues with better backlevel
>> support (mostly for OS/2 and Win9x servers) so he might have more
>> information, but the obvious holes that come to mind are:
>>
>> a) utimes to backlevel (lanman) servers
>> b) For some pre-Unicode servers it would help to be able to change the
>> code page used when translating readdir responses - so that we can
>> convert the server's readdir results from the old DBCS code pages to
>> UTF-8.
>> c) optionally zeroing pages on the client to work around the few buggy
>> old servers which don't zero on expanding file size remotely.
>> d) support for ancient dos ("core smb") servers
>>
>> There are also a few places where Jeff Layton noticed the cifs code
>> would always try the more recent smb command (which fails) and only
>> then issue the backlevel SMB command (in a few of the places, it would
>> be safe to "remember" the "operation not supported" answer or
>> equivalent so we don't have to first try a command which will always
>> fail).
>
> So it's generally people talking to older (or very old) servers that
> would be affected by this?  What options would they have if smbfs were
> removed?  Is there an alternative to smbfs that would work?  FUSE client?

They could use smbclient (an ftp like tool in the samba suite), but
there are no obvious reasons for another file system.

There are some usability improvements that could be made in mount.cifs
that might be all that is needed for 99% of the users of these very
old servers.  Currently mounting to old servers such as os/2 and win95
requires specifying a server "netbios name" (mount option
"servernetbiosname" is needed since netbiosnames are often different
than the server's tcp name) and also requires overriding the default
security settings (since the lanamn mechanism is much weaker than the
NTLMv2 and Kerberos mechanisms).   If we had an easier way of passing
information back across the mount sys call back to a mount helper this
would be easier to address (since we could send information on the
server's offered dialects and security mechanisms back to user space
so we could prompt the user).

-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/