kill security=share and security=server

[Jeremy Allison]

On Thu, Jan 27, 2011 at 09:01:02AM +1000, Andrew Bartlett wrote:
> On Wed, 2011-01-26 at 14:05 -0800, Jeremy Allison wrote:
> > On Thu, Jan 27, 2011 at 07:50:21AM +1000, Andrew Bartlett wrote:
> > > 
> > > I fully support removing security=share over SMB2, and furthermore, I
> > > would like to see it marked as deprecated even on smb1 so we can
> > > eventually remove it.  
> > > 
> > > If we are trying not to break existing configurations, then we can have
> > > the deprecated parameter this force the max protocol=smb1.
> > > 
> > > There are other ways (map to guest etc) to get what almost all sane
> > > users of security=share does.  It is also not compatible (we make it
> > > almost work with kludges) with NTLMv2, which we are trying to move to. 
> > 
> > So right now in the code, for SMB2 if you have "security = share",
> > internally we convert this to:
> > 
> > security = user
> > map to guest = bad user
> > 
> > So we actually *have* gotten rid of "security = share"
> > internally in this case for all practical purposes,
> > we just don't error out the smb2 connection if someone
> > set "security = share" in their smb.conf.
> > 
> > Does this work for everyone ? Should we do the same
> > for SMB1 in 3.6.0 ? That would remove the actual code
> > complexity for "security = share" whilst still allowing
> > old smb.conf's to work.
> 
> I'm happy with this, as long as we also add the deprecation warning (so
> we don't keep a useless parameter forever).  I disagree with Chris that
> changing 'security=share -> map to guest = bad user' is that hard to
> explain (the default for security is already user). 

Ok, I can prepare a patch that will rip out SEC_SHARE
from all codepaths except the negprot ones where it
maps the parameter into the other two described.

That should be a nice patch that deletes more than
it changes :-).

Jeremy.