DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595 Security Constraints not processed according to spec. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 15:01 --- Based on the comments, this is a spec problem/interpretation of the spec. Closing based on Craig's comments since he very closey related to the spec team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595 Security Constraints not processed according to spec. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-12-09 09:24 --- I have reed the specs 2.4 about this and compared it with the specs for 2.3. There are no real differences about this topic. But I found the problem in ignoring the Use of URL Paths. Therfore I have to reopen this BUG: The Spec state in SRV 11.1 Use of URL Paths ... 2. The container will recursively try to match the longest path-prefix: This is done by stepping down the path tree a directory at a time, using the / character as a path separator. The longest match determines the servlet selected. ... TOMCAT 4 is NOT doing this to resolve the URL of a security constraint. If TOMCAT 4 would do, than the order of the security constraints wouldn't make any difference (in my example). But as I said in my comment, TOMCAT is using the first match from the descriptor, even if there are more with LONGER path-prefix. If this would be fixed, then it will work the way one expects it (according to the specs). I was willed to send comments to the jsr expert group. But the problem is not the specs. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595 Security Constraints not processed according to spec. --- Additional Comments From [EMAIL PROTECTED] 2002-12-06 09:40 --- According to section 12.8 of the Servlet 2.3 spec All request that contain a request path that matches a URL pattern described in the web resource collection is subject to the contraint there have all security-contraints to be processed. The following example works correct in that given order, but not in that reverse, which should according to the spec: security-constraint web-resource-collection web-resource-namePrivater RM Bereich/web-resource-name url-pattern/rmonly/talentbank/*/url-pattern /web-resource-collection auth-constraint role-nameUWGL.PrivateArea.TB/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-namePrivater RM Bereich/web-resource-name url-pattern/rmonly/*/url-pattern /web-resource-collection auth-constraint role-nameUWGL.PrivateArea/role-name /auth-constraint /security-constraint Comment: It looks like the container is checking only the first contraint matching the URL and granting access, if that contraint is passed. Changing the order of the security-contraints shouldn't have an effect. If someone has the role UWGL.PrivateArea but not UWGL.PrivateArea.TB he shouldn't be able to access the resources for UWGL.PrivateArea.TB. If you change the order of the constraints in the example above, Tomcat will grant access to that resources. This is a critical security bug, I think. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595 Security Constraints not processed according to spec. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-06 17:59 --- There has been substantial discussion in the servlet spec expert group, and in the JACC expert group (JSR-115) about the precise semantics of security constraint matching. The current interpretation is that the container should pick the first constraint that has a matching URL pattern and apply it -- therefore, the order of your security constraints *is* significant. Tomcat implements this interpretation; therefore I'm going to mark this bug as INVALID (we can't change the implementation unless the specified behavior is changed). However, there are others that feel as you do about what the matching policy should be. I suggest you download the latest draft of the Servlet 2.4 Specification (it's in Proposed Final Draft state now, but that doesn't mean it is cast in concrete necessarily) and review the spec language that is planned for the next servlet version, which will be supported by Tomcat 5. You can find a link to this at: http://java.sun.com/products/servlet/ Feedback should be directed to the JSR-154 Expert Group, by mailing comments to: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10595] - Security Constraints not processed according to spec.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10595 Security Constraints not processed according to spec. --- Additional Comments From [EMAIL PROTECTED] 2002-12-06 18:13 --- I think the problem is that the spec would have to define what to do when constraints return conflicting results (some grants, some denies, plus other not relevant). This is a complex problem to solve, and I support the idea to try to do a shortcut. Some other projects, like Slide and JSR 170, are attempting to solve this by having more complex ACL systems. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
