"adrian(a)jboss.org" wrote : "mmoyses" wrote : Adrian,
| | the problem is that datasources and JCA login modules are not the only place where passwords are in plain text. There are some mbeans that don't provide a means for encryption, like SuckerPassword from messaging-service.xml, suckerPassword from messaging-jboss-beans.xml or Password from mail-service.xml.
| |
|
| Then these need to be fixed to accept security-domain configurations.
I agree. We need to make these accept Password based encryption (PBE) schemes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181568#4181568
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181568
"adrian(a)jboss.org" wrote : Why doesn't this solve the problem?
| http://www.jboss.org/community/docs/DOC-9350
| http://www.jboss.org/community/docs/DOC-9703
|
That solves the issue for JCA. But what if the user has not done the encryption and log is set to debug (community version). Logs are long lived beasts. I only have an issue with JBoss core infrastructure chewing out attribute values in debug mode when the values can be passwords.
"adrian(a)jboss.org" wrote :
| Even if you mask the password in the log, if it is an MBean attribute, it will
| be visible via JMX (and the user has access).
If we try to fix this. It will only get complicated. Visually, it would prohibit the update of the password.
"adrian(a)jboss.org" wrote :
| Additionally since we recommend changing the log level to INFO
| for production anyway, none of this will appear in the log.
I am not sure that everyone follows the recommendations.
We are not trying to make passwords totally invisible. All we are trying to do is a trivial mask to passwords in the log (we may not get a 100% hit with the masking).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181566#4181566
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181566
"mmoyses" wrote : Adrian,
| the problem is that datasources and JCA login modules are not the only place where passwords are in plain text. There are some mbeans that don't provide a means for encryption, like SuckerPassword from messaging-service.xml, suckerPassword from messaging-jboss-beans.xml or Password from mail-service.xml.
|
Then these need to be fixed to accept security-domain configurations.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181563#4181563
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181563
"adrian(a)jboss.org" wrote :
| Actually, I see the WARStructure already recognises .war files as webapps.
|
Exactly. ;-)
"adrian(a)jboss.org" wrote :
| i.e. we treat anything that ends with a .war as a war regardless
| even if it doesn't contain a WEB-INF/web.xml
|
Now I get this. It was actually really meant as an i.e.
Although in reality it already was doing this.
Hence the confusion, mostly yours. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181557#4181557
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181557
"adrian(a)jboss.org" wrote : "alesj" wrote : "adrian(a)jboss.org" wrote :
| | | wouldn't have the correct classpath, etc.
| | |
| | Why wouldn't it have correct classpath?
| |
|
| Because it the war has no WEB-INF/web.xml it is currently treated as a jar.
| i.e. the root for the war will be the classpath which is clearly wrong.
Actually, I see the WARStructure already recognises .war files as webapps.
| if (isLeaf(file) == false)
| {
| // We require either a WEB-INF or the name ends in .war
| if (file.getName().endsWith(".war") == false)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181554#4181554
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181554