kill security=share and security=server

[Jeremy Allison]

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.

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

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.

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.

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.

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

> I'd prefer to limit security=share to smb1 without breaking how the
> server works in that case.

It doesn't break the server.

> This is equally compatible, as secuirty=share will still works with smb1
> as it did before, so nothing breacks with it.
> 
> If the user wants to use new features (smb2) then it will have to change
> the config. This is perfectly reasonable to me.

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

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.

Jeremy.