Runtime.exec possible to change LOGNAME, USER env vars? 1

[hopgal]

I am trying to run a UNIX ssh command from a Java application, which needs to be run by a specific username or it won't have the correct permissions to execute. The application runs under a different username. I have tried setting the env. variables for LOGNAME and USER and USERNAME to the one I want, then executing the command like this:
String [] envVarsList = new String[3];
envVarsList[0] = "USER=wkadmin";
envVarsList[1] = "LOGNAME=wkadmin";
envVarsList[2] = "USERNAME=wkadmin";
proc = rt.exec("/usr/local/bin/ssh -2 serverName -l wkadmin -n tail /path/filename", envVarsList);
int exitVal = proc.waitFor();
log.info("ExitValue of runtime process = " + exitVal);

It returns a value of 255.

The command works fine when I run it outside the Java program, so I know it will work if I just can get the env. variables right. Is this possible to do with Runtime.exec?

 

[Diancecht]

Humm, from my point of wiew, that should work.

I'd try checking the values of the env variables at runtime with an echo.

Cheers,

Dian

 

[stefanwagner]

public Process exec(String[] cmdarray,
String[] envp)
throws IOException
Executes the specified command and arguments in a separate process with the specified environment.

This is a convenience method. An invocation of the form exec(cmdarray, envp) behaves in exactly the same way as the invocation exec(cmdarray, envp, null).

Parameters:
cmdarray - array containing the command to call and its arguments.
envp - array of strings, each element of which has environment variable settings in the format name=value, or null if the subprocess should inherit the environment of the current process

(from the javadocs)

The way you took with the envp is the way you should try with the cmd.


seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[hopgal]

No, changing the env params didn't work. Even though the env appears to have the parameters set as I requested, the ssh command is still prompting me for a password as if it is being executed by someone other than wkadmin, and my process is still returning 255. Here is my output:

Executing env command
stream= LOGNAME=wkadmin
stream= USER=wkadmin
stream= USERNAME=wkadmin
stream= PATH=/usr/bin:/usr/bin::/usr/local/bin:/usr/local/bin
Executing command
Reading input stream from command:
wkadmin@hyperion's password:
method returned 255

Danke, stefanwagner, aber: method signature exec(String cmd,String[] envp) works the same, it "applies StringTokenizer to break the string into tokens and creates a new array cmdarray containing the tokens in the order that they were produced by the string tokenizer; it then performs the call exec(cmdarray, envp)." So, I don't think this is my problem, it is that the env variables are somehow not being seen by the runtime process.

At this point I am thinking I will have to send the encrypted password to get this to work, or else try another, less elegant way to do this.

 

[Diancecht]

What about a little sh with some prior setenvs? Or a command line of type setenv 1 & setenv 2 & ssh?

Cheers,

Dian

 

[stefanwagner]

I heard something about a jssh.jar short ago but don't remember where.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[stefanwagner]

Or this small article about: "From Runtime.exec() to ProcessBuilder" helps?

http://java.sun.com/developer/JDCTechTips/2005/tt0727.html

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[hopgal]

stefanwagner: Yes, this might help, thanks, I will check it out! As it is, I have been working with the IS Security people to change the ssh key to the one the app is really running under (most of the time). However, since this sometimes runs under root as well, it is not an ideal solution because it is unpredictable who will be starting the server, and it should not matter to my application.

dianececht: I am using a shell script, but if I have to sudo in to the userName I want, there are problems with that too, because even with sudo no password set up, it still prompts for a password on the destination node!

Right now I am waiting for a new build to see if the new ssh keys will work. It has been an interesting exercise in Runtime.exec, sudo and ssh, that's for sure.