kill security=share and security=server

[Andrew Bartlett]

On Fri, 2011-01-28 at 02:16 +0900, TAKAHASHI Motonobu wrote:
> 2011/1/27 Andrew Bartlett <abartlet at samba.org>:
> >> On Wed, 2011-01-26 at 15:11 -0600, Christopher R. Hertel wrote:
> >> Unfortunately, for SMB1 many people still use share-mode authentication in
> >> low-level applications, such as home servers.
> >
> > Home servers are the easy case, as 'map to guest = bad user' will handle
> > it very well.
> 
> One important advantage about "security = share" is to set both
> read-only password and read-write password to each shares.
> 
> Some users still use "security = share" for this purpose.
> 
> The mapping will only confuse people, I think.
> If you decide to remove "security = share", simply to  remove is the best.

Does this still work?  For which clients can you not simply specify
'readuser/password' and 'writeuser/password'?  

Can you give me an example of a working configuration (client and
server) that actually uses this?

The reason I ask is that for clients that send NTLMv2 (Vista), this
can't work for more than the trivial case that we can do with
security=user, map to guest=bad user.  Samba clients have for some time
refused to connect to security=share servers unless configured to send
LM passwords on the client. 

NTLMv2 ties the password response to a username, and the only username
it can tie it to is the one in the session setup.  This means you can't
do read and write passwords with NTLMv2.  If that isn't the username we
end up authenticating as, then it will fail. 

That is why I so fully support removing this code completely.  This was
code I was scared of 10 years ago when I first did the auth rewrite, and
still don't like.  It is complex, security sensitive code, and it has so
little hope of working fully with modern clients (Vista or above), and
the main use case (I just want to get to my shares) has a simple
equivalent. 

Having security=share force the max protocol certainly would work, but I
think we miss an opportunity to simply remove this feature, and explain
to our users that we wanted to have SMB2 consistently available, and not
magically disabled by an apparently unrelated smb.conf option. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.