force group broken in 3.5 for anon ntlmssp

[Jeremy Allison]

On Sat, Nov 13, 2010 at 11:59:38PM +0100, Volker Lendecke wrote:
> Hi, Jeremy!
> 
> It's late here, I just want to dump in on you for
> cross-checking. That's worth putting into 3.5 I think, but
> before creating a bug I'd like you to take a look.
> 
> Volker

> >From 53f2b9f0ad1977471b8b87569a38c27a4ac3d711 Mon Sep 17 00:00:00 2001
> From: Volker Lendecke <vl at samba.org>
> Date: Sat, 13 Nov 2010 18:03:25 +0100
> Subject: [PATCH] s3: Fix "force group" with ntlmssp guest session setup
> 
> This one is subtle: Set "force group = <somegroup>" together with "guest ok =
> yes". Then try "smbclient //server/share -U%". Works. Then try to connect to
> the same share from Windows 2003 using an anonymous connection. Breaks with
> 
> make_connection: connection to share denied due to security descriptor
> 
> although the share_info.tdb is empty. I've seen reports of this on the lists,
> but I could never ever nail it until a customer gave me access to such a box.
> 
> What happens? With an empty share_info.tdb we create a security descriptor
> allow everything to the world. The problem with the above parameter combination
> is that S-1-1-0 (World) is lost in the token. When you look at the callers of
> create_local_token, they are only called if the preceding check_ntlm_password
> did not create server_info->ptok. Not so with the one in auth_ntlmssp.c. So, if
> we get a NTLMSSP session setup with user="", domain="", pass="" we call
> create_local_token even though check_guest_security() via
> make_server_info_guest() has already correctly done so. In this case
> create_local_token puts S-1-1-0 into user_sids[1], which is supposed to be the
> primary group sid of the user logging in. "force group" then overwrites this ->
> the world is gone -> "denied due to security descriptor".
> 
> Why don't you see it with smbclient -U% (anonymous connection)? smbclient does
> not use ntlmssp for anon session setup.
> 
> This seems not to happen to 3.6.

Wow - amazing analysis. I concur with your findings in reading your
description and the code (although I'm going to have to test this myself).
I want to know why it doesn't happen with 3.6 though :-).

Jeremy.