Brad, Fixed means fixed in the source code repository. It'll be included in the next build, and that build will be ready when it's ready. If you want it sooner, build Tomcat from SVN trunk.
(This is how Tomcat and most other FOSS projects operate) Yoav --- Brad O'Hearne <[EMAIL PROTECTED]> wrote: > Bill, > > If I am reading this right, it says the bug is fixed. When will there > be a new release that contains this fix? (Sorry for my ignorance on > the organization of Tomcat builds). > > B > > On Oct 20, 2005, at 9:15 PM, Bill Barker wrote: > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=37044 > > > > ----- Original Message ----- From: "Brad O'Hearne" > > <[EMAIL PROTECTED]> > > To: "Tomcat Developers List" <dev@tomcat.apache.org> > > Sent: Thursday, October 20, 2005 8:35 PM > > Subject: Bug in RealmBase, JAASRealm, and/or Requestt object > > preventing proper role authorization > > > > > > > >> All, > >> > >> I have discovered a bug in role authorization when using a > >> JAASRealm and > >> custom user / role principals. In a nutshell, successful > >> authentication in > >> the JAASRealm over a custom JAAS login module results in the > >> JAASRealm > >> pulling the user principal and role principals out of the > >> authenticated > >> subject and wrapping them inside a GenericPrincipal object. The > >> generic > >> principle object is then stored in the request. Then, when > >> permissions are > >> being checked in RealmBase.hasResourcePermission(), the following > >> line of > >> code is executed to retrieve the user principal: > >> > >> Principal principal = request.getUserPrincipal(); > >> > >> This method didn't return the wrapping generic principle, it > >> returned my > >> custom user principle. The code for the requests getUserPrincipal > >> () method is > >> as follows: > >> > >> public Principal getUserPrincipal() { > >> if (userPrincipal instanceof GenericPrincipal) { > >> return ((GenericPrincipal) > >> userPrincipal).getUserPrincipal(); > >> } else { > >> return (userPrincipal); > >> } > >> } > >> > >> Everything looks great so far, until you get to the logic which > >> actually > >> checks the permissions. The RealmBase.hasRole() method starts with > >> this block > >> of code (with an interesting opening comment): > >> > >> // Should be overriten in JAASRealm - to avoid pretty > >> inefficient > >> conversions > >> if ((principal == null) || (role == null) || > >> !(principal instanceof GenericPrincipal)) > >> return (false); > >> > >> When this statement executes, principal is not a GenericPrincipal, > >> by merits > >> of the request's getUserPrincipal() method executed prior to > >> calling this > >> method -- it is instead a custom user principal. This causes the > >> third part > >> of the if condition to be true, causing the method to return > >> false, and the > >> method to fail, and authorization to fail. So in other words, > >> whenever a > >> custom principal is used, role authorization should be failing, > >> and since > >> this is in RealmBase, not the JAASRealm subclass, I am assuming > >> that anyone > >> with a custom principal isn't able to authorize any roles properly. > >> > >> The quick response might be to just use a GenericPrincipal type as > >> your custom > >> principle. But this doesn't make sense either, because the hasRole > >> method is > >> seeking the roles within the GenericPrincpal object (the user > >> principal) > >> which must contain all the roles. This is what is done by the > >> Realm code > >> already. The problem is that the hasRole method needs the > >> GenericPrincipal > >> wrapper that contains the roles, NOT the custom user principal > >> which does not > >> contain the roles. > >> > >> It would be great if I am missing something But if not, I don't > >> know if where > >> you want to consider the culprit for the bug, but it is certainly > >> a bug, and > >> it breaks authorization. Please let me know what the options are > >> for getting > >> this bug fixed, as it prevents container managed security in > >> Tomcat using > >> JAAS. > >> > >> Thanks, > >> > >> Brad > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > > This message is intended only for the use of the person(s) listed > > above as the intended recipient(s), and may contain information > > that is PRIVILEGED and CONFIDENTIAL. If you are not an intended > > recipient, you may not read, copy, or distribute this message or > > any attachment. If you received this communication in error, please > > notify us immediately by e-mail and then delete all copies of this > > message and any attachments. > > > > In addition you should be aware that ordinary (unencrypted) e-mail > > sent through the Internet is not secure. Do not send confidential > > or sensitive information, such as social security numbers, account > > numbers, personal identification numbers and passwords, to us via > > ordinary (unencrypted) e-mail. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
