ACLs on Attributes that do not have attributeSecurityGUID

[Andrew Bartlett]

On Sun, 2012-12-30 at 16:56 +0200, Nadezhda Ivanova wrote:
> Hi Andrew,
>  As far as I remember, the attributesecurityguid contains the property
> set to which the attribute belongs, and some permissions are given per
> property set rather than an attribute. We build an object tree with
> the object as root, property sets as children and attributes as their
> children and apply all permissions, so that when we get to the bottom
> of the tree we have the final permissions mask for that attribute. (I
> really have to think of a way to optimize this code, I do not
> particularly like it.) If there isn't a attributesecurityguid, we add
> the attribute directly under the ObjectId. I took a look at the code,
> and do not see an obvious bug (acl_check_access_on_attribute
> in acl_util.c) which does not mean there isn't one. Do you have a
> particular example or even better, a test that fails? That will really
> help with debugging. 

So, the issue I see is that I can't see where the overriding or fallback
'read all attributes' is processed. 

As an example, in make testenv:

bin/samba-tool user add abartlet penguin12# -s st/dc/etc/smb.conf 
bin/ldbsearch -H ldap://localdc cn=administrator -Uabartlet%penguin12#
--configfile=st/dc/etc/smb.conf  > /tmp/5
bin/ldbsearch -H ldap://localdc cn=administrator -Uadministrator%
$PASSWORD --configfile=st/dc/etc/smb.conf  > /tmp/6

diff -u /tmp/5 /tmp/6

[abartlet at jesse samba]$ diff -u /tmp/5 /tmp/6
--- /tmp/5      2012-12-30 21:17:13.273658690 +1100
+++ /tmp/6      2012-12-30 21:17:32.234667964 +1100
@@ -6,23 +6,31 @@
 objectClass: user
 cn: Administrator
 description: Built-in account for administering the computer/domain
+instanceType: 4
+whenCreated: 20121230100558.0Z
+whenChanged: 20121230100558.0Z
+uSNCreated: 3544
+uSNChanged: 3544
 name: Administrator
 objectGUID: 31f93dcd-1734-46e3-872f-fd9d2ad72f48
 userAccountControl: 512
 badPwdCount: 0
 codePage: 0
 countryCode: 0
+badPasswordTime: 0
 lastLogoff: 0
 lastLogon: 0
 pwdLastSet: 130013355580000000
 primaryGroupID: 513
 objectSid: S-1-5-21-3677849678-1690126113-1927719212-500
+adminCount: 1
 accountExpires: 9223372036854775807
 logonCount: 0
 sAMAccountName: Administrator
 sAMAccountType: 805306368
 objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=samba,DC=example,DC=co
  m
+isCriticalSystemObject: TRUE
 memberOf: CN=Administrators,CN=Builtin,DC=samba,DC=example,DC=com
 memberOf: CN=Group Policy Creator
Owners,CN=Users,DC=samba,DC=example,DC=com
 memberOf: CN=Enterprise Admins,CN=Users,DC=samba,DC=example,DC=com

The thing that is different about the attributes shown in this diff is
that they do not have an attributeSecurityGUID.  I've noticed that the
ACLs only seem to include mentions of the attributeSecurityGUID values,
not the individual attribute GUIDs.  What I've not yet managed to find
is what ACE is meant to reflect the "read all attributes" intent, and
how it is processed.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org