kill security=share and security=server

Christopher R. Hertel crh at samba.org
Wed Jan 26 15:12:25 MST 2011


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.

It works for me.  Having to explain security = user / map to guest = bad
user to home users, vendors, etc. seems like a lot more work.

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


More information about the samba-technical mailing list