request to remove security=share

[Christopher R. Hertel]

Andrew Bartlett wrote:
> On Tue, 2006-03-14 at 17:18 -0600, Steven French wrote:
> 
>>>but it is so trivial to support
>>
>>Perhaps one case in which it is nicer to be working on the "client"
>>side :)
>>
>>The client is easy  ... as it is still is NTLM (would be fun to allow
>>NTLMv2), just skip session setup and stick the encrypted challenge in
>>the tconx

That is the way real share-mode works.  In the old days, it was the
plaintext password that was returned in the tconx.  Now it's the response
(the encryption of the challenge).

> The problem is the username arguments in the hash calculation.
> Otherwise, this would sort of almost work (due to the way this is
> plumbed)

That's why Volker proposed the "share write user" and "share read user"
options.  It ties the share to a password (or a pair or password) using
the existing user lookup mechanisms which already work.  It also bypasses
all of the cruft of trying to "guess" a username so that a password can be
found.  Finally, it forces one single password per access option
(read/write) rather than going through a list of possibilities as we do
now.  That makes the whole thing much more consistent (and simpler).

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