RE: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent()

[Poonam Parhar]

Hello Shafi,

You could do something like this:

+ public static void error(AgentConfigurationError e) {
+String keyText = getText(e.getError());
+String params = e.getParams();
+
+System.err.print(getText("agent.err.error") + ": " + keyText);
+
+if (params != null && params.length != 0) {
+   StringBuffer message = new StringBuffer(params[0]);
+   for (int i = 1; i < params.length; i++) {
+   message.append(" " + params[i]);
+   }
+   System.err.println(": " + message);
+}
+e.printStackTrace();
+throw new RuntimeException(e);
+ }

This error() variant first prints the 'error' and 'params' of the 
AgentConfigurationError and then prints the complete stack trace (including the 
cause).

Daniel,

Originally, if the stack trace was intentionally ignored to keep the error 
message short, then I think just printing the 'cause' instead of complete stack 
trace would also be sufficient in getting to the cause of the error here.

Instead of 

e.printStackTrace();

we can just do:

System.err.println("Caused by: " + e.getCause());


Thanks,
Poonam


> -Original Message-
> From: Daniel Fuchs
> Sent: Thursday, April 13, 2017 2:25 AM
> To: David Holmes; Shafi Ahmad; serviceability-dev@openjdk.java.net
> Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in
> sun.management.Agent#startAgent()
> 
> On 13/04/2017 02:15, David Holmes wrote:
> > Overall the exception management in this code looks like it predate
> > the existence of an "exception cause" and should probably be updated
> > to utilize that more effectively.
> 
> Hi David,
> 
> I think the original idea was to display a localized message to the end
> user - and not frighten him with a big unlocalized stack trace.
> 
> But I otherwise agree with your suggestion.
> 
> best regards,
> 
> -- daniel

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

[Harsha Wardhana B]

Hi Gruss,

Crypt format has additional params (|param|name and its|value|: hash 
complexity parameters, like rounds/iterations count ) which are not 
applicable to current implementation. Also,  hash algorithms shipped 
with JDK are applicable (MD5, SHA1, SHA256) and any other algorithms 
specified by crypt format will be ignored.


Crypt format can be used, but it is over-engineered for current 
requirement/implementation. I am not opposed to using it and would 
welcome input from other reviewers.


-Harsha

On Sunday 23 April 2017 08:10 PM, Bernd Eckenfels wrote:
Hm, why introduce a new password hash format. Just use modular crypt() 
format (and iterations). This allows to use common tools (like 
htpasswd) to generate the hashes. It would use $5$ prefix for SHA256 
but actually I would use $6$ for iterated SHA512 as it is the default 
on most recent Linux distributions.


Gruss
Bernd
--
http://bernd.eckenfels.net

*From:* serviceability-dev 
 on behalf of Harsha 
Wardhana B 

*Sent:* Sunday, April 23, 2017 12:20:57 PM
*To:* serviceability-dev@openjdk.java.net
*Subject:* RFE Review : JDK-5016517 - Replace plaintext passwords by 
hashed passwords for out-of-the-box JMX Agent


Hi All,

Please review this enhancement to replace plain-text password for JMX 
agent with SHA-256 hash.


Issue: https://bugs.openjdk.java.net/browse/JDK-5016517


webrev: http://cr.openjdk.java.net/~hb/5016517/webrev.00/

Overview of implementation:

Currently, the JMX agent password file used to authenticate user, 
stores user name and password as clear text. Though system level 
restrictions are recommended for jmx password file, passwords are 
vulnerable since they are stored in clear. The current RFE proposes to 
store passwords as SHA256 hash instead of clear text.


In current implementation, if password file is writable, and if 
passwords are in clear, they will be replaced by SHA256 hash upon 
agent boot-up or when login attempt is made.


The file, 
src/jdk.management.agent/share/conf/jmxremote.password.template 
contains more details about the implementation.


- Harsha