[PATCH] Remove non-guest security=share from master

[Andrew Bartlett]

Oops, I forgot to CC Kai and Motonobu Takahashi.

I would appreciate any thoughts at all on this.  I know all of you have
expressed views about this issue in the past, and any comment on the
specific proposed patch would be most appreciated.

I refer specifically to the top 3 patches on:
http://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/s3-secshare

Thanks,

Andrew Bartlett

On Fri, 2012-02-03 at 19:13 +1100, Andrew Bartlett wrote:
> Attached is a proposed set of patches to make 'security=server' map all
> incoming users as 'guest' accounts, which I would like to get into
> master for 4.0.
> 
> The reason I'm so keen to remove security=server is because I strongly
> dislike the username guessing that has to be done to map 'per share'
> password to an account:
> 	/* there are several possibilities:
> 		1) login as the given user with given password
> 		2) login as a previously registered username with the given
> 		   password
> 		3) login as a session list username with the given password
> 		4) login as a previously validated user/password pair
> 		5) login as the "user =" user with given password
> 		6) login as the "user =" user with no password
> 		   (guest connection)
>                 7) any member of a group specified in user= as @group
>                 8) the netbios name of the client and the given password
> 		9) login as guest user with no password
> 
> 		if the service is guest_only then steps 1 to 5 are skipped
> 
> Additionally I dislike this code because we do not keep the state from
> the authentication for use as the user's session info - we instead trust
> the incoming username again. 
> 
> Also, NTLMv2 logins, which are becoming the norm, also have many
> challenges with security=share, because as you 'guess' the username, you
> throw off that part of the hash calculation. 
> 
> Finally, I simply think that it is time that this old corner of the
> protocol to be put to rest, particularly as we move to SMB2 which simply
> cannot support it. 
> 
> I've CC'ed a number of you, my fellow developers, because I want to know
> if this patch is acceptable to you.  I know you have all expressed your
> views to me on security=share in the past year that I've been talking
> about removing it.  I propose this particular patch because it is
> simple, it removes some quite complex code, and the outcomes are
> predictable (guest access or no access).  
> 
> Kai, in addressing your concern:  Users who just want to connect to
> their home server on a trusted network can still do so easily.
> 
> Volker:  I know you strongly feel that we cannot remove features like
> this.  Does the mapping to guest address any of your concerns?  Could
> you live with this feature being retired for 4.0, or if not, is there
> any part of the complexity that can be acceptably removed?
> 
> Motonobu Takahashi:  I understand this patch would break the complex
> configuration you posted last year, with a 'read password' and 'write
> password' for a given share.  Do you think this could be acceptably
> migrated to a 'read user' and 'write user' by the time you deploy Samba
> 4.0?
> 
> Thanks,
> 
> Andrew Bartlett 

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