kill security=share and security=server

[TAKAHASHI Motonobu]

2011/1/28 Andrew Bartlett <abartlet at samba.org>:
> On Fri, 2011-01-28 at 02:16 +0900, TAKAHASHI Motonobu wrote:
>> 2011/1/27 Andrew Bartlett <abartlet at samba.org>:
>> >> On Wed, 2011-01-26 at 15:11 -0600, Christopher R. Hertel wrote:
>> >> Unfortunately, for SMB1 many people still use share-mode authentication in
>> >> low-level applications, such as home servers.
>> >
>> > Home servers are the easy case, as 'map to guest = bad user' will handle
>> > it very well.
>>
>> One important advantage about "security = share" is to set both
>> read-only password and read-write password to each shares.
>>
>> Some users still use "security = share" for this purpose.
>>
>> The mapping will only confuse people, I think.
>> If you decide to remove "security = share", simply to  remove is the best.
>
> Does this still work?  For which clients can you not simply specify
> 'readuser/password' and 'writeuser/password'?
>
> Can you give me an example of a working configuration (client and
> server) that actually uses this?

Here is the configuration which works with Samba 3.5.6 and Windows XP SP3:

-----
[global]
  security = share
  passdb backend = tdbsam

[share1]
  path = /var/lib/samba/shares/share1
  write list = share1rw
  username = share1ro, share1rw

[share2]
  path = /var/lib/samba/shares/share2
  write list = share2rw
  username = share2ro, share2rw
-----

cf. https://bugzilla.samba.org/show_bug.cgi?id=1254

2011/1/28 Jeremy Allison <jra at samba.org>:
> Indeed - we have *never* supported this on the server.

2011/1/28 Christopher R. Hertel <crh at samba.org>:
> Jeremy Allison wrote:
>> On Thu, Jan 27, 2011 at 04:07:46PM -0500, simo wrote:
>>> If I understood chris message correctly, you are ""not breaking"
>>> smb.conf but you are braking share level security for smb1, so you are
>>> breaking actual use cases.
>>
>> No, I'm not. I'm mapping share level security for smb1 into
>> something we already do internally.
>
> Agreed.  Samba has never supported actual share level authentication the way
> it was originally designed (for DOS).  You describe this below.

Of course I understand. My smb.conf above is something tricky.

2011/1/28 Andrew Bartlett <abartlet at samba.org>:
> The reason I ask is that for clients that send NTLMv2 (Vista), this
> can't work for more than the trivial case that we can do with
> security=user, map to guest=bad user.  Samba clients have for some time
> refused to connect to security=share servers unless configured to send
> LM passwords on the client.
>
> NTLMv2 ties the password response to a username, and the only username
> it can tie it to is the one in the session setup.  This means you can't
> do read and write passwords with NTLMv2.  If that isn't the username we
> end up authenticating as, then it will fail.
>
> That is why I so fully support removing this code completely.  This was
> code I was scared of 10 years ago when I first did the auth rewrite, and
> still don't like.  It is complex, security sensitive code, and it has so
> little hope of working fully with modern clients (Vista or above), and
> the main use case (I just want to get to my shares) has a simple
> equivalent.
>
> Having security=share force the max protocol certainly would work, but I
> think we miss an opportunity to simply remove this feature, and explain
> to our users that we wanted to have SMB2 consistently available, and not
> magically disabled by an apparently unrelated smb.conf option.
>
> Andrew Bartlett

I agree that removing "security = share" from Samba 4 just for your reason.
But I think it's not a minor change so should not do from Samba 3.x release.

And  I agree not to support SMB2 under "security = share" in Samba 3.x, too.
We do not need  to add new features to "security = share".

---
TAKAHASHI Motonobu <monyo at samba.gr.jp>