Related
I'm running in to an error when I try to run my server application from Eclipse. The error is java.net.BindException: Permission denied. I think this is because I am using port 443 to set up an SSL connection. I can get around this problem if I run my code on the command line using java and sudo. Is there a way to set up Eclipse so that when I hit the run button, my application is executed with sudo?
You can follow these steps to compile/debug applications as superuser.
Rename your java-application
sudo mv /usr/lib/jvm/java-6-openjdk/jre/bin/java /usr/lib/jvm/java-6-openjdk/jre/bin/java.ori
Create following script and store it as /usr/lib/jvm/java-6-openjdk/jre/bin/java
#!/bin/bash
# file: /usr/lib/jvm/java-6-openjdk/jre/bin/java
# descr: Starter for jdk. Runs jdk as root when
# cmd-line-arg "--run-as-root" is specified.
#
jre="/usr/lib/jvm/java-6-openjdk/jre/bin/java.ori"
run_as_root=false
args=
# Filter command-line argument
for arg in "$#"
do
case "$arg" in
--run-as-root) run_as_root=true
;;
*) args="$args $arg"
;;
esac
done
# Remove leading whitespaces
args=$(echo $args | sed -e 's/^[ \t]*//')
if $run_as_root
then
echo "WARNING: Running as root!"
gksu "$jre $args"
else
$jre $args
fi
Change the permissions to make it executable
sudo chmod 0755 /usr/lib/jvm/java-6-openjdk/jre/bin/java
Startup eclipse
Go to Window->Preferences->Java->Installed JREs
Duplicate java-6-openjdk to java-6-openjdk-root
Edit JRE and add "--run-as-root" as Default VM Argument
To run projects as root you need to follow these steps:
Go to Project->Properties->Java Build Path
Double-Click the JRE System Library and choose in Alternate JRE "java-6-openjdk-root"
Note: The idea is from http://www.eclipse.org/forums/index.php/mv/msg/87353/724852/#msg_724852
Assuming you are on Linux (*nix),
How about starting your eclipse session via a sudo command?
Such as
sudo ~/eclipse/eclipse
Now whatever you do from eclipse will have the sudo context?
As mentioned in this thread:
In order to open a port below 1024 on Unix/Linux systems you need to be
"root".
I also used the argument -Dorg.eclipse.equinox.http.jetty.port=8080 to change the listen port, but this seems to be ignored (according to the stacktrace)
Please use "-Dorg.osgi.service.http.port=8080".
As mentioned in HTTP Service:
org.osgi.service.http.port - specifies the port number to use for the http serving. The default value for this property is 80 (which requires root permission), as per the OSGi specification.
org.osgi.service.http.port.secure - specifies the port number to use for secure http serving. The default value for this property is 443 (which requires root permission), as per the OSGi specification.
Maybe if you try to modify that last property to a value above 1024 it could work without requiring any special privilege.
Another option would be to use iptables or ipfilter to forward port 80 to a port above 1024.
(Can someone contribute a link to a practical and easy-to-understand explanation ?)
A better answer, perhaps, if this serves your needs AND is possible, could be simple port redirection on your router.
Instead of trying to force your linux/unix to open a reserved port, when you are only developing this now (not installing) and you want to run it in a debugger,
set your router to redirect incoming (external) port 443 to a port that is more convenient for your current needs (say 4443).
I think most routers support this, and if yours doesn't it gives your mum a good christmas or birthday present idea!
I am writing C not Java but this should work in either case.
I use remote debug - define a "remote" connection to LOCALHOST which allows you to specify the user you will connect with, specify ROOT. Then define a Remote Application in debug configuration connection: LOCALHOST. Be sure to check "skip download to target path" at the bottom of the main tab as well as under the connection properties window.
You can use Remote Java Application mechanism for this.
Create Debug configuration for Remote Java Application
section in Run -> Debug configurations...
Set your project name
Choose Connection type as Standard (Socket Attach)
Configure Connection properties parameters for your binding
(for you it will be localhost and 443).
Set breakpoint in your app (e.g. at the beginning of the main method)
Run your app from terminal as superuser with following command: java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=443 MyApp
Hit debug button in Eclipse for early created Remote Java Application
You code should be stopped on breakpoint in Eclipse!
If you use External tools (Run menu/External tools or an icon next to the Run/Debug icons on the toolbar), you can use any scripts or whatever you like. The scripts may give you elevated rights, or whatever.
On the other hand, this way debugging the application can become very hard, as neither the Run nor Debug commands get associated with this External tool configuration. Maybe it is possible to connect the Eclipse debugger of the application, but I don't know, how that is possible.
You may go this way
create a Makefile with javac calls
add the following line:
setcap 'cap_net_admin=+ep' Server
configure sudo to allow your Eclipse user to run setcap.
So you will have a transparent debugging (no sudo wrapper - gdb ok).
Cons: it is a local security breach.
Solution:
put this to /opt/my-stupid-eclipse
#!/bin/sh
setcap 'cap_net_admin=+ep cap_net_raw=+ep' $1
chmod +x this script and whitelist it on sudo config.
username ALL=(ALL) NOPASSWD: /opt/my-stupid-eclipse
Add it to your makefile, specify path to your Server binary.
Now you have pretty strange but secure script, that cannot be changed by other users... and still a little breach for replacing Server binary with any malicious code, that will gain caps, so no filename check/stricts will help.. can $1 be contaminated with bash commands, no? Guess, no.
I am trying to update RJava to reflect the latest version of Java 1.8 on my mac. I think I found the right information in doing so but the issue arises when I use 'Terminal' to run some code. I have to run:
sudo R CMD javareconf -n
but I receive an error of:
sudo: R: command not found
I found some information online and I found out I need to change the path in Terminal. I found out that the path where R is '/usr/bin/R'. When I changed the path using the command:
export PATH=/usr/bin/R:$PATH
and then tried to run the code again; I got no where and I am out of luck. I don't understand what the code is but I can only assuming what it does. Hopefully I can get some insight on how I can change the path so I can update rJava to the updated Java Version. Thank you for anyone's time.
The PATH setting would be PATH=/usr/bin:$PATH or you even easier
sudo /usr/bin/R CMD javareconf
Note that -n wouldn't do anything so you probably didn't mean that. Also if you don't even have /usr/bin on your PATH, you have probably even bigger issues since you also need to find java in the first place. In cases like that you may have better luck using sudo -i and then using the shell to fix whatever env vars are not setup correctly in your system.
I have a Jenkins config that executes Java tests for OS X app using Maven. And when I'm trying to run some AppleScript that requires assistive access for it, different errors appear. So I've tried to execute AppleScript in two ways:
Using ScriptEngine:
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine engine = mgr.getEngineByName("AppleScriptEngine");
engine.eval(script);
In this case script execution fails with error: An error of type -10810 has occurred.
Calling osascript. In this case error looks like: System Events got an error: osascript is not allowed assistive access. (-1719)
In accessibility list I have following things: SystemUIServer, Script Editor, osascript, java, mvn, bash, Terminal. When running script in Script Editor or in osascript from Terminal, script passed without any errors.
Any suggestions what else should I check?
I think you answer your own question. You can allow assistive access for Script Editor (among other things). It works fine in Script Editor.
You can try and add other applications to have assistive access. This might be an option if Script Editor does not give you want you want.
I find that I sometimes need to add the parent of the process that calls osascript, in addition to osascript itself, regardless of what the error message says. Sometimes I have to add the grandparent process too.
In particular, /bin/bash does not call any assistive API, but OSX wants it listed even though osascript is also listed, and I've had to add TeamCity's agent.jar too.
So try adding your .jar file, and look to see whether ScriptEngine uses an intermediate code executor that you'll also need to enable.
Beware that you'll probably have to remove and add your entries if you change the binary (I think OSX maintains some sort of checksum in the final binary entry in its database entry).
Another workaround is to write the AppleScript using Script Editor, save it as a standalone app from there, and give that app assistive access. Then you can run the app as needed from another environment like a Java app or Automator workflow.
See also: https://apple.stackexchange.com/a/346306/264883
I've resolved something like this problem before by inserting osascript into the TCC.db using tccutil.py
After installing I linked tccutil.py into the path.
sudo ln -s /source/tccutil/tccutil.py /usr/bin/tccutil.py
ls -l /usr/bin/tccutil.py
lrwxr-xr-x 1 root wheel 26 30 Dec 14:57 /usr/bin/tccutil.py -> /source/tccutil/tccutil.py
Then to allow osascript access to control your computer use the following compand
sudo tccutil.py --insert /usr/bin/osascript
I even added the script when the problem happened again later on.
sudo tccutil.py --insert $(pwd)/transcribe-audio-to-text.js
That failed so I rebooted which worked :-)
transcribe-audio-to-text.js currently uses System Events to make TextEdit be able to save a text file. It's part of virtual assistant which is very alpha at 20160105 but the source is interesting. virtual-assistant
I have a script using java to connect to display X11 in the port 10.0 at localhost
but i get always this error
java.lang.InternalError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:62)
at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:178)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:142)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:112)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at java.awt.Toolkit$2.run(Toolkit.java:849)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:841)
at ij.io.Opener.openJpegOrGif(Opener.java:367)
at ij.io.Opener.openImage(Opener.java:220)
at ij.io.Opener.openImage(Opener.java:249)
at ij.io.Opener.open(Opener.java:116)
at ij.IJ.open(IJ.java:1112)
at ij.macro.Functions.open(Functions.java:2006)
at ij.macro.Functions.doFunction(Functions.java:129)
at ij.macro.Interpreter.doStatement(Interpreter.java:205)
at ij.macro.Interpreter.doBlock(Interpreter.java:515)
at ij.macro.Interpreter.runUserFunction(Interpreter.java:278)
at ij.macro.Interpreter.getFactor(Interpreter.java:1200)
at ij.macro.Interpreter.getTerm(Interpreter.java:1162)
at ij.macro.Interpreter.getExpression(Interpreter.java:1145)
at ij.macro.Interpreter.getBooleanExpression(Interpreter.java:881)
at ij.macro.Interpreter.getLogicalExpression(Interpreter.java:857)
at ij.macro.Interpreter.getBoolean(Interpreter.java:850)
at ij.macro.Interpreter.doIf(Interpreter.java:829)
at ij.macro.Interpreter.doStatement(Interpreter.java:217)
at ij.macro.Interpreter.doBlock(Interpreter.java:515)
at ij.macro.Interpreter.doStatement(Interpreter.java:241)
at ij.macro.Interpreter.doIf(Interpreter.java:831)
at ij.macro.Interpreter.doStatement(Interpreter.java:217)
at ij.macro.Interpreter.doStatements(Interpreter.java:195)
at ij.macro.Interpreter.run(Interpreter.java:99)
at ij.macro.Interpreter.run(Interpreter.java:65)
at ij.macro.Interpreter.run(Interpreter.java:75)
at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:127)
at ij.plugin.Macro_Runner.runMacroFile(Macro_Runner.java:112)
at ij.IJ.runMacroFile(IJ.java:103)
at ij.ImageJ.main(ImageJ.java:517)
I have tried everything to solve this problem like :
export DISPLAY=:10.0
export DISPLAY=localhost:10.0
I tried also the port 0.0 but i get always the same error
after trying xhost
xhost +local:all
xhost: unable to open display ""
xhost: unable to open display ":10.0"
how can i fix this
i thought that the X Server is not runing so i tried startx its says its runing at that port
my system is Ubuntu server edition 10.04
You need to specify the -Djava.awt.headless=true parameter at startup time.
Remove the DISPLAY variable
unset DISPLAY
This helps in most cases (e.g. starting application servers or other java based tools) and avoids to modify all that many command lines.
It can also be comfortable to add it to the .bash_profile for a dedicated app-server/tools user.
This command helped me to solve the problem:
export DISPLAY=:0
I think you are working in sudo mode.Please checkout to the user mode and try again
In case anybody trying to run the automated unit tests via maven-surefire-plugin on CI(jenkins,..), and getting the above mentioned error, be sure to update your surefire plugin configuration :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
<configuration>
<systemPropertyVariables>
<java.awt.headless>true</java.awt.headless>
</systemPropertyVariables>
</configuration>
</plugin>
This will fix it:
/usr/bin/java -Djava.awt.headless=true $Your_program
For me logging in as -Y instead of -X worked.
In case you've got untrusted X11 as shown below, then try -Y flag instead (if you trust the host):
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
If you are trying to export display using su and it still doesn't work.
This is what worked for me. Try X11 forwarding for sudo users.
Connect the remote host using the -X option with ssh.
# ssh -X root#remote-host
Now list the coockie set for the current user.
# xauth list $DISPLAY
node01.thegeekdiary.com/unix:10 MIT-MAGIC-COOKIE-1 dacbc5765ec54a1d7115a172147866aa
# echo $DSIPLAY
localhost:10.0
Switch to another user account using sudo. Add the cookie from the command output above to the sudo user.
# sudo su - [user]
# xauth add node01.thegeekdiary.com/unix:10 MIT-MAGIC-COOKIE-1 dacbc5765ec54a1d7115a172147866aa
Export the display from step 2 again for the sudo user. Try the command xclock to verify if the x client applications are working as expected.
# export DISPLAY=localhost:10.0
source: https://www.thegeekdiary.com/how-to-set-x11-forwarding-export-remote-display-for-users-who-switch-accounts-using-sudo/
This fixed my problem
xhost +
but Be aware that xhost + completely deactivates authentication and allows everyone to access all application on your screen.
xhost +si:localuser:root seems to work similar with proper authentication.
First: start XQuartz
Second: ssh -X user#ip_address
...: start your process
if you ssh and then start XQuartz you will get that error
After several days of futile effort of installing glassfish on raspberry pi 2 with headless fedora 22, Below worked for me without a hitch
unset DISPLAY
java -Djava.awt.headless=true -jar glassfissh-installer-v2ur2-b04-linux.jar
got my help from here
I was using Xming and got similar error. Following steps were taken to fix the issue:
In Xming launch check the box no access control.
In putty ran the following command: DISPLAY=XXX.XXX.XXX.XX:0.0; export DISPLAY
Replace XXX.XXX.XXX.XX with your IP address.
First do this either in Build Phase of Jenkins if using or set in /etc/profile:
unset DISPLAY
export DISPLAY=:0
then set this property either in java code or using maven:
-Djava.awt.headless=false
Solved. I just logout and login with xorg!
check whether $DISPLAY variable is set or not, with the below command:
echo $DISPLAY
if the display variable is not set, run the below command to set, (even if it is set, you can have below one for your session)
export DISPLAY=:0.0
in putty also have the x display location as :0.0
Michael-O gave useful approach to solve the problem. Another way to solve this is by starting the server with Putty Console.
In my case there was no space left in my machine and I faced the same issue.
Some times it could be the space issue. Check the space in your Linux/Unix environment and make sure your machine have enough space.
For Ubuntu 17.10
Install X virtual frame buffer (xvfb)
apt install xvfb
And added these lines to the /etc/profile file...
# Start the X virtual frame buffer (Xvfb)
if [ -f /usr/X11R6/bin/Xvfb ]; then
/usr/X11R6/bin/Xvfb :1 -screen 0 1366x768x32
fi
# Set the DISPLAY variable for the X virtual frame buffer (Xvfb)
export DISPLAY=localhost:1.0
I had the same issue on the Linux server I was working on. Connecting java to a X11 display worked on the head node, but not on any other. After contacting the administrator, it turned out that the current version of our job-scheduling system (SLURM) did not support X11 forwarding. They had to update SLURM (newer versions of SLURM support it) for it to work.
the only way i got it to work was running the script with a template. e.g. sudo ./glassfish-3.1.2.2-unix.sh -s template
This installs Glassfish in Silent Mode. http://docs.oracle.com/cd/E18930_01/html/821-2427/ghmva.html
I run into the same error with you when i run the jconsole command at remote. I want to modify a parameter at jconsole that run on a remote Linux host, i can login the host use the secureCRT, the terminal throw this error information. Fortunately, when use the Putty, it's ok. Weird....
If you see this error in Hudson, try to remove the .java directory from your home directory, it may work for you.
If you start application on a remote server while logged in by ssh then another way would be to start ssh with -x parameter or add ForwardX11 no in your /etc/ssh/ssh_config. In this case ssh will not create environment variable DISPLAY.
If you're triggering your code from Jenkins, enabling the option "Start Xvfb before the build, and shut it down after" might help. It helped me.
change to a another user and try except root. it works for me.
I just didn't log out of root before running ./studio.sh All set.
In my case this error was not related to the DISPLAY port. I was trying to load an XML into Windchill (a PLM-software) and received only the above error on the terminal. In a logfile I found the report that my XML-file was corrupt. Maybe someone has a similar problem and can use this answer.
Mine issue was with the firewall. Disabled it temporarily.
[EDIT] And, the server hostname was pointing to another IP. Set it to simply localserver. strace xclock helped to debug this issue.
I have fixed this issue by logging in using Xorg. By default, I have used Wayland. It looks like Wayland eliminates most of the design flaws of the Xorg it has its own issues.
For me none of the above worked, but after long search this worked for me.
export DISPLAY=localhost:20.0
I'm running in to an error when I try to run my server application from Eclipse. The error is java.net.BindException: Permission denied. I think this is because I am using port 443 to set up an SSL connection. I can get around this problem if I run my code on the command line using java and sudo. Is there a way to set up Eclipse so that when I hit the run button, my application is executed with sudo?
You can follow these steps to compile/debug applications as superuser.
Rename your java-application
sudo mv /usr/lib/jvm/java-6-openjdk/jre/bin/java /usr/lib/jvm/java-6-openjdk/jre/bin/java.ori
Create following script and store it as /usr/lib/jvm/java-6-openjdk/jre/bin/java
#!/bin/bash
# file: /usr/lib/jvm/java-6-openjdk/jre/bin/java
# descr: Starter for jdk. Runs jdk as root when
# cmd-line-arg "--run-as-root" is specified.
#
jre="/usr/lib/jvm/java-6-openjdk/jre/bin/java.ori"
run_as_root=false
args=
# Filter command-line argument
for arg in "$#"
do
case "$arg" in
--run-as-root) run_as_root=true
;;
*) args="$args $arg"
;;
esac
done
# Remove leading whitespaces
args=$(echo $args | sed -e 's/^[ \t]*//')
if $run_as_root
then
echo "WARNING: Running as root!"
gksu "$jre $args"
else
$jre $args
fi
Change the permissions to make it executable
sudo chmod 0755 /usr/lib/jvm/java-6-openjdk/jre/bin/java
Startup eclipse
Go to Window->Preferences->Java->Installed JREs
Duplicate java-6-openjdk to java-6-openjdk-root
Edit JRE and add "--run-as-root" as Default VM Argument
To run projects as root you need to follow these steps:
Go to Project->Properties->Java Build Path
Double-Click the JRE System Library and choose in Alternate JRE "java-6-openjdk-root"
Note: The idea is from http://www.eclipse.org/forums/index.php/mv/msg/87353/724852/#msg_724852
Assuming you are on Linux (*nix),
How about starting your eclipse session via a sudo command?
Such as
sudo ~/eclipse/eclipse
Now whatever you do from eclipse will have the sudo context?
As mentioned in this thread:
In order to open a port below 1024 on Unix/Linux systems you need to be
"root".
I also used the argument -Dorg.eclipse.equinox.http.jetty.port=8080 to change the listen port, but this seems to be ignored (according to the stacktrace)
Please use "-Dorg.osgi.service.http.port=8080".
As mentioned in HTTP Service:
org.osgi.service.http.port - specifies the port number to use for the http serving. The default value for this property is 80 (which requires root permission), as per the OSGi specification.
org.osgi.service.http.port.secure - specifies the port number to use for secure http serving. The default value for this property is 443 (which requires root permission), as per the OSGi specification.
Maybe if you try to modify that last property to a value above 1024 it could work without requiring any special privilege.
Another option would be to use iptables or ipfilter to forward port 80 to a port above 1024.
(Can someone contribute a link to a practical and easy-to-understand explanation ?)
A better answer, perhaps, if this serves your needs AND is possible, could be simple port redirection on your router.
Instead of trying to force your linux/unix to open a reserved port, when you are only developing this now (not installing) and you want to run it in a debugger,
set your router to redirect incoming (external) port 443 to a port that is more convenient for your current needs (say 4443).
I think most routers support this, and if yours doesn't it gives your mum a good christmas or birthday present idea!
I am writing C not Java but this should work in either case.
I use remote debug - define a "remote" connection to LOCALHOST which allows you to specify the user you will connect with, specify ROOT. Then define a Remote Application in debug configuration connection: LOCALHOST. Be sure to check "skip download to target path" at the bottom of the main tab as well as under the connection properties window.
You can use Remote Java Application mechanism for this.
Create Debug configuration for Remote Java Application
section in Run -> Debug configurations...
Set your project name
Choose Connection type as Standard (Socket Attach)
Configure Connection properties parameters for your binding
(for you it will be localhost and 443).
Set breakpoint in your app (e.g. at the beginning of the main method)
Run your app from terminal as superuser with following command: java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=443 MyApp
Hit debug button in Eclipse for early created Remote Java Application
You code should be stopped on breakpoint in Eclipse!
If you use External tools (Run menu/External tools or an icon next to the Run/Debug icons on the toolbar), you can use any scripts or whatever you like. The scripts may give you elevated rights, or whatever.
On the other hand, this way debugging the application can become very hard, as neither the Run nor Debug commands get associated with this External tool configuration. Maybe it is possible to connect the Eclipse debugger of the application, but I don't know, how that is possible.
You may go this way
create a Makefile with javac calls
add the following line:
setcap 'cap_net_admin=+ep' Server
configure sudo to allow your Eclipse user to run setcap.
So you will have a transparent debugging (no sudo wrapper - gdb ok).
Cons: it is a local security breach.
Solution:
put this to /opt/my-stupid-eclipse
#!/bin/sh
setcap 'cap_net_admin=+ep cap_net_raw=+ep' $1
chmod +x this script and whitelist it on sudo config.
username ALL=(ALL) NOPASSWD: /opt/my-stupid-eclipse
Add it to your makefile, specify path to your Server binary.
Now you have pretty strange but secure script, that cannot be changed by other users... and still a little breach for replacing Server binary with any malicious code, that will gain caps, so no filename check/stricts will help.. can $1 be contaminated with bash commands, no? Guess, no.