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

[Andrew Bartlett]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-auth-Make-security-share-permit-only-guest-logins.patch
Type: text/x-patch
Size: 23204 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120203/b47c575e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-s3-auth-Add-make_session_info_from_pw-to-avoid-multi.patch
Type: text/x-patch
Size: 3561 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120203/b47c575e/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-s3-auth-Tidy-up-security-share-handler.patch
Type: text/x-patch
Size: 2938 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120203/b47c575e/attachment-0002.bin>