On enabling read ACLs on LDAP searches for 4.0

[Stefan (metze) Metzmacher]

Hi Nadezhda,

> Hi Andrew and Metze,
> Does this mean that with Metze's work, the read ACLs no longer break a ton
> of tests in make test? If so, that makes me very happy :).
> Metze, thank you so much for picking up where I failed to continue!

Yes, exactly. The only things I need to change were other modules :-)

metze

> On Wed, Nov 21, 2012 at 8:44 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> 
>> Metze,
>>
>> I'm delighted to see the work you have done recently, and incredibly
>> pleased to see that we have the chance to protect the data in an AD
>> server we are hosting with the read ACLs that the administrator
>> specified.
>>
>> It is really important that, particularly in a situation where we join
>> an existing domain, we can still protect that information as well as a
>> Microsoft server would.  This eliminates unexpected surprises that some
>> might describe as security holes, and puts into production work a great
>> and impressive effort by Nadya.
>>
>> As such, I'm really exited by this, and I'm quite keen that our users
>> get to have this in Samba 4.0, given the patches are available.
>>
>> That said, I'm also cautious - you would of course remember my caution
>> around the DNS server change, and this is even more 'last moment' than
>> that was.  There are really important issues to consider, such as if we
>> break some of the harder to test features (eg, running a wintest to
>> verify interactions with Windows), and if we are really delivering what
>> we are promising.
>>
>> Some specific concerns:
>>  - constraints for DB integrity (wouldn't want ACLs to somehow allow
>> duplicate user creation because you can't see one!)
>>  - while at the same time as avoiding information leaks such as might
>> happen if a 'helper' search was substantially controlled by the caller
>> was invoke 'AS_SYSTEM' as I understand you do
>>
>> My view at RC1 stage (when we first discussed if this blocker bug and
>> discussed DNS) was that this would be a 'new feature' and it was too
>> late to add it in, but now I'm not so certain, or so black-and-white.
>> In short, this isn't 'just another feature'.
>>
>> The fact that we got this far without solving another serious ACL issue
>> (for GPOs) has rattled my confidence a little, but I'm not sure that
>> means we should leave this as a known issue for a whole release cycle.
>>
>> My gut feeling is to enable this, audit it carefully (both before and
>> after the release), and allow users to turn if off if it causes issues.
>> Adding an 'acl:search=false' would get users back to where we are now,
>> and is an easily described fallback.  But doing this rests on our
>> extensive automated tests (of which I'm very grateful), a similar
>> battery of manual tests and a careful review of the code.
>>
>> Andrew Bartlett
>> --
>> Andrew Bartlett                                http://samba.org/~abartlet/
>> Authentication Developer, Samba Team           http://samba.org
>>
>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20121121/6ddd0588/attachment.pgp>