2015-11-22 22:26 GMT+03:00 Christopher Schultz <ch...@christopherschultz.net>: > Konstantin, > > On 11/21/15 10:07 AM, Konstantin Kolinko wrote: >> 2015-11-20 15:47 GMT+03:00 Christopher Schultz >> <ch...@christopherschultz.net>: >>> All, >>> >>> I thought there was a BZ issue for this, but I didn't find one. It's >>> been suggested (and I agree completely) that an application ought to be >>> able to fetch the CredentialHandler for the context's realm so that it >>> could mutate user credentials in the same way that the Realm expects to >>> do. That allows applications to change user's passwords, for instance. >>> >> >> In review of r1715434 >> >> 1. I think this has to be an opt-in feature. >> >> I do not see high risk though. In theory, if stored credentials are >> known then CredentialHandler allows untrusted applications to test >> potential passwords without triggering a lock-out timer. > > Hmm, I hadn't thought of that. I could pretty easily make this a setting > for the context. > >> I am OK with this being a StandardContext feature, though there is an >> alternative way: to implement publishing the attribute with a >> Listener. > > But then if you don't trust the application, how do you trust the > context's settings? >
1) When SecurityManager is enabled then the value of "deployXML" attribute of a StandatdHost by default is "false". It means that an administrator has to explicitly configure a conf/Catalina/localhost/appname.xml context file for an application, if it needs one. The META-INF/context.xml file in a web application is not trusted. (Moreover, Tomcat will refuse to start an application if META-INF/context.xml is present, but explicit context file in conf/ is not configured). 2) In case of "user" applications deployed by org.apache.catalina.startup.UserConfig listener: A Context is created programmatically, with default settings (the value for StandardContext.configFile is null). The META-INF/context.xml file in a web application is not read. > What kind of listener do you think would be appropriate to use, here? > I just say that it is another possible way to implement this feature. A LifecycleListener that reacts on "after_start" or "configure_start" event of a Context. >> 2. A web application is not allowed to access classes in org.apache.catalina. >> >> Interfaces exposed to web applications (InstanceManager etc.) are in >> org.apache.tomcat package >> and access to them is granted with the following lines in catalina.policy: >> >> // All JSPs need to be able to read this package >> permission java.lang.RuntimePermission >> "accessClassInPackage.org.apache.tomcat"; > > Hmm... I didn't test with a SecurityManager enabled; didn't think about > that. > > I think Mark committed the original work for CredentialHandler based > upon my ideas... Mark, is there any objection to moving > CredentialHandler to org.apache.tomcat? It would be an API change, but > we could leave org.apache.catalina.CredentialHandler as a sub-interface > of the new one in org.apache.tomcat. > > Another idea would be continue to use the existing CredentialHandler > internally, and put the "SafeCredentialHandler" for access through the > ServletContext into org.apache.tomcat. Your web application that uses CredentialHandler class, does it also use other internal classes? Do you need access to a Realm? Or you are accessing a database / LDAP directory directly, behind a Realm's back? E.g. LockOutRealm has a cache of locked-out users. You may want to call LockOutRealm.unlock(username) if user's password is being reset by an administrator. If CredentialHandler is not the only class you need access to then moving it alone does not solve your issue. To allow access to other classes there has to be an explicit grant in catalina.policy file, like there is one for Tomcat Manager application. I think it is OK to leave CredentialHandler as is as long as it is not exposed by default. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
