Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 27433 invoked from network); 25 Oct 2005 10:43:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Oct 2005 10:43:45 -0000 Received: (qmail 21064 invoked by uid 500); 25 Oct 2005 10:43:43 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 21008 invoked by uid 500); 25 Oct 2005 10:43:43 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 20997 invoked by uid 99); 25 Oct 2005 10:43:43 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Oct 2005 03:43:43 -0700 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.205 as permitted sender) Received: from [64.233.184.205] (HELO wproxy.gmail.com) (64.233.184.205) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Oct 2005 03:43:41 -0700 Received: by wproxy.gmail.com with SMTP id i21so554152wra for ; Tue, 25 Oct 2005 03:43:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ahUnCuvetmqDs9//c0KsHSMR8jqHin0I9yPdhWLcvQgMW4KsMK1tEZyXtQAh4bQsc/7UJjLNJaV0B58FO4wDNbxaGAVnwKkNZyRVmaNZ89yL3N3cJIihZAX0HaAq5YlMk41SGlgo9vtVy6GlpjsXILaGhrhS1SXBeVPVbDQr/K8= Received: by 10.54.145.18 with SMTP id s18mr3518535wrd; Tue, 25 Oct 2005 03:43:21 -0700 (PDT) Received: by 10.54.71.11 with HTTP; Tue, 25 Oct 2005 03:43:21 -0700 (PDT) Message-ID: <768dcb2e0510250343i4d883c7es@mail.gmail.com> Date: Tue, 25 Oct 2005 19:43:21 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: [apacheds]ACI support classes never consider "attributeValue" in ACIItem In-Reply-To: <4355CDE7.5090400@bellsouth.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_39104_23520172.1130237001566" References: <4355CDE7.5090400@bellsouth.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_39104_23520172.1130237001566 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2005/10/19, Alex Karasulu : > > Trustin, > > Within the o.a.l.s.authz.support package nothing checks to see if the > "attributeValue" field in a protectedItem is adhered too. For this > reason permission checks are failing. Let me give you an example that I > have in a testcase: > > I have the following ACIItem: > > { > identificationTag "searchAci" > precedence 14 > authenticationLevel none, > itemOrUserFirst userFirst: > { > userClasses { allUsers }, > userPermissions > { > { > protectedItems {entry, attributeType { ou }, allAttributeValues > { objectClass }, attributeValue { ou=3D0, ou=3D1, ou=3D2 } }, grantsAndDe= nials > { grantRead, grantReturnDN, grantBrowse } } > } > } > } > > This should only allow the return of ou values that are "0", "1" and "2" > and not allow the return of other ou values in a search. However it's > not doing that. Nothing in the support pkg seems to test to see if the > value is equal to any of these values. > > Could you advise on what's happening? It was because RelatedProtectedItemFilter didn't ignore AttributeType when operationScope is not ATTRIBUTE_TYPE_AND_VALUE. Now it should work fine. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_39104_23520172.1130237001566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2005/10/19, Alex Karasulu <aok12= 3@bellsouth.net>:
Trustin,

Within the o.a.l.s.authz.support package nothing checks to = see if the
"attributeValue" field in a protectedItem is adhere= d too.  For this
reason permission checks are failing. &n= bsp;Let me give you an example that I
have in a testcase:

I have the following ACIItem:

{
&n= bsp; identificationTag "searchAci"
  precedence= 14
  authenticationLevel none,
  itemOrUserFirst= userFirst:
  {
    userClasses { allUs= ers },
    userPermissions
    {      {
     &nb= sp;   protectedItems {entry, attributeType { ou }, allAttributeVa= lues
{ objectClass }, attributeValue { ou=3D0, ou=3D1, ou=3D2 } }, grant= sAndDenials
{ grantRead, grantReturnDN, grantBrowse } }
      }
  }
}

This= should only allow the return of ou values that are "0", "1&= quot; and "2"
and not allow the return of other ou values in a= search.  However it's
not doing that.  Nothing in t= he support pkg seems to test to see if the
value is equal to any of these values.

Could you advise on what'= s happening?

It was because RelatedProtectedItemFilter= didn't ignore AttributeType when operationScope is not ATTRIBUTE_TYPE_AND_= VALUE.  Now it should work fine.

Trustin
--
what we call human nature is actually= human habit
--
http://gleamynode.= net/ ------=_Part_39104_23520172.1130237001566--