Better empty DACL approach

[Matt Zinkevicius]

Hi,
My ACL database code started barfing on ACLs with empty ACE lists with the
cvs snapshot I just got. I traced it to Tim/Jeremy's change in parse_sec.c:

--- samba/source/rpc_parse/parse_sec.c	2001/02/27 19:22:29	1.26.4.11
+++ samba/source/rpc_parse/parse_sec.c	2001/06/26 06:15:55	1.26.4.12
@@ -135,7 +135,14 @@
 	dst->num_aces = num_aces;
 	dst->size = 8;

-	if((dst->ace = (SEC_ACE *)talloc(ctx, sizeof(SEC_ACE) * num_aces )) ==
NULL) {
+	/* Now we need to return a non-NULL address for the ace list even
+	   if the number of aces required is zero.  This is because there
+	   is a distinct difference between a NULL ace and an ace with zero
+	   entries in it.  This is achieved by always making the number of
+	   bytes allocated by talloc() positive.  Heh. */
+
+	if((dst->ace = (SEC_ACE *)talloc(ctx, sizeof(SEC_ACE) * num_aces + 1))
+	   == NULL) {
 		return NULL;
 	}

This is not the correct way to handle this. You don't have to waste memory,
you should just check that the security descriptor's type contains the
DACL_PRESENT bit whenever you're computing the effective rights. If it's not
there then you have full access, otherwise loop though the aces. If ace_cnt
== 0 then your loop terminates giving no access. You're code should never
try to dereference the ace[] array unless ace_cnt > 0, so this num_aces+1
talloc is bogus. Here is the patch I applied to my tree to allow empty DACLs
a while back:

--- samba-2.2.0-orig/source/rpc_parse/parse_sec.c Tue Feb 27 19:22:29 2001
+++ samba-2.2.0-acldb/source/rpc_parse/parse_sec.c Fri Jun 22 12:15:12 2001
@@ -135,7 +135,7 @@
  dst->num_aces = num_aces;
  dst->size = 8;

- if((dst->ace = (SEC_ACE *)talloc(ctx, sizeof(SEC_ACE) * num_aces )) ==
NULL) {
+ if((num_aces) && ((dst->ace = (SEC_ACE *)talloc(ctx, sizeof(SEC_ACE) *
num_aces )) == NULL)) {
   return NULL;
  }


Up to you guys since your fix will work for everybody else, but it will be
one less difference between our trees, which will be nice once HP let's me
release my patch, and it's not such a blatant hack ;-)

--Matt Zinkevicius