kill security=share and security=server

[Christopher R. Hertel]

Jeremy Allison wrote:
> On Thu, Jan 27, 2011 at 04:07:46PM -0500, simo wrote:
>> If I understood chris message correctly, you are ""not breaking"
>> smb.conf but you are braking share level security for smb1, so you are
>> breaking actual use cases.
> 
> No, I'm not. I'm mapping share level security for smb1 into
> something we already do internally.

Agreed.  Samba has never supported actual share level authentication the way
it was originally designed (for DOS).  You describe this below.

> Look - the only clients that use share level security *ON
> THE WIRE* are Win9x and prior.

The client isn't in control.  Win9x *servers* support share level
authentication.  I have not tested newer clients recently but if they allow
plaintext passwords to be passed they may very well perform share level
authentication on the wire.

The only NT LM 0.12 *servers* that I know of that support share level
authentication are W9x.

> Remember, Samba has *never* supported share level security
> on the server (i.e. you can't set a global password for a
> share) - we have *always* mapped into UNIX users - even before
> Win9x was common.

Right.  Exactly right, but I believe that if security=share is set Samba
still clears the NEGOTIATE_USER_SECURITY (0x01) bit of the SecurityMode
field in the NegProt response.  That indicates to the client that the client
MUST use share level authentication.

> What we did was take the password sent in the TCON when
> the server tells the client it was using share level security,
> and then tried to find an existing UNIX user for whom that
> smbpassword matches.
> 
> What the proposed patch does is stop allowing that negotiation
> on the wire - so clients now *HAVE* to do an SMBsessionsetup
> call, not just a TCON call to connect.

This is a requirement of the NT LM 0.12 dialect in any case, and everything
from W95 upward negotiates NT LM 0.12 for SMB1.

Here's some trivia:  SessionSetupAndX wasn't even defined in the core
protocol.  The original protocol did not support user-based authentication
at all.  SessionSetupAndX was introduced with OS/2 LANMAN 1.0.

> That's why it's such a small patch - it just removes how we
> read the passwords off the wire for the old style TCON, and
> removes the code that allows clients to send invalid VUIDs
> for connections in "share level" security.

Right...  or an Anonymous logon.  Since NT LM 0.12 requires the
SessionSetupAndX, the only possible way to do a share level authentication
(in that dialect) would be to perform an anonymous logon first.

...that would give you a valid [V]UID, but not one that helps in any way.

> The only possible clients this might break are DOS 3.x
> clients.

...and OS/2, technically.  WfWG is still really DOS.

> I want to move us to a case where share level security doesn't
> exist anymore, for SMB1 or SMB2.

Share level authentication is part of SMB1, so it's really a question of
whether or not Samba supports it and, if so, how.

> I'm ok with doing that for Samba4 only, but I do want to get
> there. And I want to do it without breaking anyones existing
> working config.

I'm being typically pedantic in my descriptions, but I'm fundamentally
agreeing with your approach.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org