Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=lA/Yan4Oy9OIgo74v1/uK0+DcDciu5qCiqU8zzvn6rVGI6KuZMOFpnRSJcK8BRcCCzhn6Y0B/5rUn96ePY8QbFsKv2qsz5ctWXJgIeVHyPLtKl0UvAEwOtzMbQAGT2E0xVZse4LImx673aMGSokHaLhFoaoLhYgU+HLBC9Hcomk=
  ;
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <42E999D8.5000301@savoirtech.com>
References: <42E9938D.5060808@optusnet.com.au>
 <42E999D8.5000301@savoirtech.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <f713af9c9e7a606fbd90f899b6ef9dfc@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Potential Security Bug?
Date: Thu, 28 Jul 2005 22:44:22 -0700
To: dev@geronimo.apache.org

I think our behavior is correct.  I don't quite understand what the 
other possibilities are.  FWIW, I don't think we should   bend over 
backward to support jsp pages not mentioned web.xml.

thanks
david jencks

On Jul 28, 2005, at 7:52 PM, Jeff Genender wrote:

> Yes...there might be a bug here...
>
> IIRC, the Jetty JACC code did not test for JACC v1.0 section B.19 
> which is an explicit test for JSPs under JACC.  I am not sure if this 
> is the case here...but it sounds like it.
>
> I would like to see what David Jencks or Alan thinks about this.
>
> Jeff
>
> Gianny Damour wrote:
>> Hi,
>> I have been trying to understand why I was not able to make the Java 
>> Pet Store Supplier Application to pass a security check and I think 
>> that I have discovered a potential bug. Prior to log it, I would like 
>> to confirm that this is not a code issue in PetStore.
>> The scenario is rather simple:
>> * the url "/RcvrRequestProcessor" is secured and only the 
>> "administator" role can access it;
>> * a FORM based authentication is configured to log in the users;
>> * the url "/RcvrRequestProcessor" plays the role of a dispatcher 
>> servlet and forwards to the jsp file "/displayinventory.jsp";
>> * within the jsp "/displayinventory.jsp" there is the following 
>> security check " request.isUserInRole("administrator")"; and
>> * this security check fails.
>> I think that the security configuration is OK as I can log in and 
>> successfully access the url "/RcvrRequestProcessor", which requires 
>> an "administrator" role.
>> However, isUserInRole fails. This is the Permission which is tested:
>> (javax.security.jacc.WebRoleRefPermission jsp administrator)
>> Against the following Permissions:
>> java.security.Permissions@93139 (
>> (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor 
>> GET,POST)
>> (javax.security.jacc.WebRoleRefPermission PopulateServlet 
>> administrator)
>> (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor 
>> administrator)
>> )
>> The "jsp" portion of the Permission being tested is the name of the 
>> servlet being processed and comes from a JettyServletHolder 
>> automatically registered for the processing of jsp files.
>> If I add to the web.xml DD the following elements to explicitly 
>> register the jsp "/displayinventory.jsp", then isUserInRole works as 
>> expected:
>>  <servlet>
>>    <servlet-name>/displayinventory.jsp</servlet-name>
>>    <jsp-file>/displayinventory.jsp</jsp-file>
>>  </servlet>
>>  <servlet-mapping>
>>    <servlet-name>/displayinventory.jsp</servlet-name>
>>    <url-pattern>/displayinventory.jsp</url-pattern>
>>  </servlet-mapping>
>> Indeed, with this explicit mapping, when isUserInRole is executed, 
>> the Permission to be tested is:
>> (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp 
>> administrator)
>> And the Permissions is:
>> java.security.Permissions@18ef578 (
>> (javax.security.jacc.WebRoleRefPermission /displayinventory.jsp 
>> administrator)
>> (javax.security.jacc.WebRoleRefPermission PopulateServlet 
>> administrator)
>> (javax.security.jacc.WebRoleRefPermission RcvrRequestProcessor 
>> administrator)
>> (javax.security.jacc.WebResourcePermission /RcvrRequestProcessor 
>> GET,POST)
>> )
>> As a matter of fact, I am not sure if this is a bug in our 
>> implementation or in PetStore (FYI, I have found another 
>> configuration issue for an ejb-jar.xml DD).
>> Any idea?
>> Thanks,
>> Gianny
>