There is a client who would like to install a custom Java application on his business owned computers, However, he doesn't want to give the ability for the limited users to close the application, even from Windows Task Manager.
The purpose of the application is to monitor some specific resources and do several tasks silently. The users of these computers will be aware of this software and what it does exactly.
I couldn't find a way to do this by using the Java programming language! Is it possible or it's mainly related to Windows users' permissions and capabilities system?
You can't do such a thing in the program itself. It is more of a system level thing. Try launching the JVM (java.exe) as a System process.
You could run it as a Windows service, started by the Administrator. That way, users won't be able to close the process as they do not have high enough privileges.
Refer to http://wrapper.tanukisoftware.com/doc/english/download.jsp for a fantastic wrapper that you can use.
For a short tutorial, look at http://wrapper.tanukisoftware.com/doc/english/launch-win.html
Having something unclosable and invisible sounds unethical, but I'd imagine it does have legitimate uses. If it is for something worthwhile like protecting vulnerable people online etc. then they should probably not have task manager access in the first place, preventing them from stopping the JVM. Consider user privileges over attempting to code around corners.
Related
I'm running a J2SE application that is somewhat trusted (Minecraft) but will likely contain completely un-trusted (and likely even some hostile) plugins.
I'd like to create a plugin that can access the GPIO pins on the Raspberry PI.
Every solution I've seen requires that such an app be given sudo-superpowers because gpio is accessed through direct memory access.
It looks like the correct solution is to supply a command-line option like this:
-Djava.security.policy=java.policy
which seems to default you to no permissions (even access to files and high ports), then add the ones your app needs back in with the policy file.
In effect you seem to be giving Java "sudo" powers and then trusting java's security model to only give appropriate powers out to various classes. I'm guessing this makes the app safe to run with sudo--is this correct?
Funny that I've been using Java pretty much daily since 1.0 and never needed this before... You learn something new every day.
[Disclaimer: I'm not very convinced by the Java security model.]
The way I would solve this is to have the code that needs to access the hardware run as a separate privileged process, then have your Java application run as an unprivileged process and connect to the privileged process to have it perform certain actions on its behalf.
In the privileged process, you should check with maximum distrust each request whether it is safe to execute. If you are afraid that other unprivileged processes might connect to the daemon too and make it execute commands it shouldn't, you could make its socket owned by a special group and setgid() the Java application to that group by a tiny wrapper written in C before it is started.
Unix domain sockets are probably the best choice but if you want to chroot() the Java application, a TCP/IP socket might be needed.
My program is a distributed software for a small laboratory. It is written in java but because during daytime the computers are used, I have to manually restart it in the evening. I would solve the problem by starting it from a service every time the computer is started but I need a mechanism to detect:
1) user input(mouse, keyboard etc.)
2) user logon
Detecting any user input from java it is not possible. Is there any framework for something like this?
Detecting user input from Java is possible, but not with standard tecnologies. Considering the excellent example of aTunes, you can do it using, depending upon your platform
JIntelliType on Windows
JXGrabKey on Linux
Considering your other question, I would use native abilities of client OSes to better handle your problem. First thing is to make your Java process lower priority. This way, it will run all time long, without having the user blocked by it. I would also force this program to stop when CPU load is over a given target. This can be achieved using JMX, as this previous question explains.
I have a Java project that uses the Bluecove Library, this library requires root privileges to do certain actions that I require in my project. I should note here that despite the project being Java based it is for Linux only.
The project will have many functions that do not require root privileges, some of which will have to interact with the root privilege functions and some that will not.
Additionally, the project will execute programs such as hciconfig using user inputted data under root privileges.
All this root activity has led me to be concerned about the security of my system. The target machine would be the user's own computer and there is no intention of running this system on some public terminal but security is still important as unknown external bluetooth devices will be capable of interacting with this system.
So far my security measures have involved heavily filtering user input, and paying very careful attention to all actions that external bluetooth devices will cause the system to perform but I am growing increasingly unhappy with this.
What would people recommend? One thought would be to split the system in to two or three modules, one containing the GUI and non-root backend, one containing the Bluecove root backend and possibly a root wrapper for hciconfig and the other tools used.
I have noticed some programs, for example Apache, that once run "drop down" their privileges. How is this achieved and is this effective?
What apache does it the setuid system call (in libc), which as you noted, effectively drops down the privilege of the process. You can make libc call via JNI, or JNA.
This works very well, even for Java programs, except that once you go from root to non-root, you won't be able to perform any operations that require the elevated privileges. So the technique can be only used if all the privileged operations can be done upfront, like Apache does.
Another possibility is to divide your program into two processes --- when launched, your program forks another program that runs as root, then have the original one demote to the non-root. Two processes can communicate over their stdin/stdout.
Is this possible?
With the right architecture, for many kinds of applications - sure.
Just split the GUI and "core logic" into separate processes, and have the GUI able to detect and reattach to the running backend process when you run it after the crash.
For extra robustness, given that an X crash can often take down the whole system, move to a classic client/server architecture with the backend running over the network.
No. X11 is the foundation for the window manager and then the Java Swing application that runs in that window environment. So if X11 crashes there's not much you can do.
In addition to what wrt said, your backend system could also watch for HeadlessExceptions, and handle them appropriately.
It is generally not practical for an X11 desktop application to recover from a crashed X11 service, whether it is written in Java or another language.
But it may be possible to prevent the problem happening to a Java app the first place. I recall having to deal with this a long time (5+ years) ago. Sun had a workaround that involved setting a system property to tell the JVM to not use 2D graphics acceleration. I cannot recall the details, but you may be able to find an equivalent solution on the Sun website.
We have a curious problem with our java processes dying.
The application doesn't stacktrace, or write anything to the logs, the process just randomly dies. It's a heavily used application, but the problem only appears about once a month.
We're currently looking into using Process Monitor but any other suggestions would be welcome.
Edit:
It's a distributed Java application, running on Weblogic with an in-house web framework (Yes, this is a terrible idea, but it's been running for eight years), connecting to Oracle.
-
Out of Memory?
Our logs would catch java.lang.OutOfMemoryException, according to Brian Agnew.
Write crashes to a log? I don't think Java ever gets the chance, the death is happening at a process level, rather than Java exiting.
Can you wrap it in some shell script that captures the log files (stdout/stderr) and the exit code (which should give some indication as to how it died) ? On JVM exit you can also capture machine level stats using WMI
IF the VM itself is crashing it'll leave behind an hs_err_pid... file that contains stacktraces, machine-level debug info. You can then use that to diagnose the VM issue. See this blog entry for further information.
If the problem is related to the app's behaviour, it may be worth looking at JConsole, although from your description of the issue, this sounds much more like a low level VM issue.
(I assume you're on the latest VM for your Java version number etc.)
You can use a Linux NAGIOS Server to monitor the health of your Windows machines and services! Have a look at: nagios-monitoring-windows.
If you have such problems with your java app! You should test it and debug it! Applications shouldn't die without a trace! Look for logfiles! From which vendor is the app? Or is it self written? Try to enforce another Log4J/Logger/Debug Level. Monitor your System with cacti etc. to reduce the possibilities for such a crash. Talk to the software vendor.
Is enogh memory available? Maybe the app runs out of memory? Is it a standalone java process or a java process from a tomcat/jboss server?
Have you written down the crash times to a log? Appear they in different time-slices? Or appear they nearly time-circular?
VisualVM is a new tool which makes monitoring Java applications easier:
https://visualvm.dev.java.net/description.html
"VisualVM is a tool that provides detailed information about Java applications while they are running. It provides an intuitive graphical user interface that allows you to easily see information about multiple Java applications."