I have created a singularity container that's purpose to run a java program. Everything seems to work, expect that I get the following warning:
(java:54036): dconf-CRITICAL **: 23:37:10.142: unable to create directory '/run/user/175387/dconf': Read-only file system. dconf will not work properly.
From my search, I've learned that dconf is simply a system that stores configuration settings in some binary file. The singularity container is a read-only filesystem, so it is not surprising to me that issues such as this would come up.
When I invoke the singularity container, I can bind directories from the host OS. These bound directories may be writable. Therefore, my best guess is that all I need to do is change the dconf file to be located inside one of these bound, writable directories. So, my question is simply how this can be done.
The top-level dconf help output is:
Commands:
help Show this information
read Read the value of a key
list List the contents of a dir
write Change the value of a key
reset Reset the value of a key or dir
compile Compile a binary database from keyfiles
update Update the system databases
watch Watch a path for changes
dump Dump an entire subpath to stdout
load Populate a subpath from stdin
None of these seem to relate to changing the location of the dconf file.
One workaround might be to build a writable singularity container. But I'd prefer a different solution to keep the singularity container read-only.
The simplest solution, and the one I use for GUI programs run from singularity containers, is to mount the user's run directly to the container with -B /run/user/$UID.
If you are concerned about undesired dconf settings persisting for the user, I would suggest the --writable-tmpfs flag which creates a tmpfs overlay that can be used to modify the container image until the process completes.
Related
Task: Copy Folder and contents from one vdi to another vdi. This application is internally facing within the company.
Method:
In jsp have user browse for folder
The folder selection is in a text box, the folder path is passed into an action class
The folder path is placed into a teradata table
A script is called to query the table for the source path and target path (pre-determined) and make the copy
Due Dilligence: So far I have tried the <input type="file", which selects a file, not a folder. Also, the file path is not passed through due to security reasons. I have read other possible solutions but none work.
Question: Are sevlets a viable solution, and if so, how do I create one?
I'm going to go with no. There are several reasons for this.
A Java Enterprise Edition application (be it a Servlet or Java Server Page) is not supposed to access the file system directly.
It is inherently unsafe to expose internal infrastructure through an external website.
I think you need to break it up a bit more.
Save a list of shares the server has access to in a data store of some sort, like a new teradata table or for a quick proof of concept plain text file (if you're on Linux you can use the output of something like showmount -e localhost).
Let the user pick the src share from a combobox or something similar.
Continue from your step 2.
This gives you two immediately obviously advantages, which may or may not be relevant.
You can use the system without having access to the physical shares.
You can add metadata (like description or aliases).
I have to create a jar with a java application that fulfills the following features:
There are xml data packed in the jar which are read the first time the application is started. with every consecutive start of the application the data are loaded from a dynamically created binary file.
A customer should not be able to reset the application to its primary state (e.g. if the binary file gets deleted for some reason, the application should fail to run again and give an error message).
All this should not depend on the os it is running on (which means e.g. setting a registry entry in windows won't do the job)
Summarizing I want to prevent a once started application to be reset in order to limit illegitimate reuse of the application.
Now to my ideas on how to accomplish that:
Delete the xml from the jar at the first run (so far I came to the understanding that it is not possible to let an application edit it's own jar. is that true?)
Set a variable/property/setting/whatever in the jar permanently at the first run (is that possible)
Any suggestions/ideas on how to accomplish that?
update:
I did not find a solution for this exact problem, but I found a simple workaround: along with my software I ship a certain file which gets changed after the program is started the first time. of course if someone keeps a copy of the original file he can always replace it and start over.
Any user able to delete the binary file, will, with enough time, also be able to revert any changes made in the jar. When the only existing part of the application is in the hand of the user, you won't able to prevent changes to it.
You can easily just store a backup of the original jar, make a copy, use that for one run, delete, copy the original jar, etc. You would need some sort of mechanism outside the users machine, like an activation server. The user gets one code to activate an account, and can't use that code again.
I have a piece of JAVA code which reads a few files and keeps them loaded into memory for sometime. The file handles are preserved after reading. My problem here is that I want to restrict user from deleting these files using "DEL" key or rm command.
I could achieve the same on windows by preserving file handles while on Unix rm does not honour the lock on the files. I even tried Filechannel.lock() but it did not help either.
Any suggestions are appreciated.
As long as you have the handle open, they can remove the file from a directory, but they can't delete the file. i.e. the file isn't removed until you close the file or your process dies.
I even tried Filechaanel.lock() but it did not help either.
That is because it's the directory, not the file that is being altered. e.g. if they have write access to the file but not the directory they cannot delete it.
You could also look into chattr which can be used to lock the file.
chattr +i filename
Should render the file undeletable. You can then make it deleteable again via...
chattr -i filename
There is no pure Java solution to this. In fact, I don't think there is a solution at all that doesn't have potentially nasty consequences. The fundamental problem is that UNIX / LINUX doesn't have a way to temporarily place a mandatory lock on a file. (The Linux syscall for locking a file is flock, but flock-style locks are discretionary. An application that doesn't bother to flock a file won't be affected by other applications locks on the file.)
The best you can do is to use chattr +i to set the "immutable" attribute on the file. Unfortunately, that has other effects:
The immutable file cannot be written to or linked to either.
If your application crashes without unsetting the attribute, the user is left with a file that he / she mysteriously cannot change or delete. Not even with sudo or su.
I am developing a Java Desktop Application. This app needs a configuration to be started. For this, I want to supply a defaultConfig.properties or defaultConfig.xml file with the application so that If user doesn't select any configuration, then the application will start with the help of defaultConfig file.
But I am afraid of my application crash if the user accidentally edit the defaultConfig file. So Is there any mechanism through which I can check before the start of the application that whether the config file has changed or not.
How other applications (out in the market) deal with this type of situation in which their application depends on a configuration file?
If the user edited the config file accidentally or intentionally, then the application won't run in future unless he re-installs the application.
I agree with David in that using a MD5 hash is a good and simple way to accomplish what you want.
Basically you would use the MD5 hashing code provided by the JDK (or somewhere else) to generate a hash-code based on the default data in Config.xml, and save that hash-code to a file (or hardcode it into the function that does the checking). Then each time your application starts load the hash-code that you saved to the file, and then load the Config.xml file and again generate a hash-code from it, compare the saved hash-code to the one generated from the loaded config file, if they are the same then the data has not changed, if they are different, then the data has been modified.
However as others are suggesting if the file should not be editable by the user then you should consider storing the configuration in a manner that the user can not easily edit. The easiest thing I can think of would be to wrap the Output Stream that you are using to write the Config.xml file in a GZIP Output Stream. Not only will this make it difficult for the user to edit the configuration file, but it will also cause the Config.xml file to take up less space.
I am not at all sure that this is a good approach but if you want to go ahead with this you can compute a hash of the configuration file (say md5) and recompute and compare every time the app starts.
Come to think of it, if the user is forbidden to edit a file why expose it? Stick it in a jar file for example, far away from the user's eyes.
If the default configuration is not supposed to be edited, perhaps you don't really want to store it in a file in the first place? Could you not store the default values of the configuration in the code directly?
Remove write permissions for the file. This way the user gets a warning before trying to change the file.
Add a hash or checksum and verify this before loading file
For added security, you can replace the simple hash with a cryptographic signature.
From I have found online so far there seems to be different approaches code wise. none appear to be a 100 hundred percent fix, ex:
The DirectoryWatcher implements
AbstractResourceWatcher to monitor a
specified directory.
Code found here twit88.com develop-a-java-file-watcher
one problem encountered was If I copy
a large file from a remote network
source to the local directory being
monitored, that file will still show
up in the directory listing, but
before the network copy has completed.
If I try to do almost anything non
trivial to the file at that moment
like move it to another directory or
open it for writing, an exception will
be thrown because really the file is
not yet completely there and the OS
still has a write lock on it.
found on the same site, further below.
How the program works It accepts a ResourceListener class, which is FileListener. If a change is detected in the program a onAdd, onChange, or onDelete event will be thrown and passing the file to.
will keep searching for more solutions.
Is there a way to search an entire computer for a String value representing a file name in Java? This would be without knowing the names of the drives on the computer.
You can iterate through the file system by looking at file names, getting the contents if it's a directory, etc. recursively.
If the sticking point is how to get the drives on the computer, look at the File.listRoots() function to get a list of the drive letters.
ETA:
To be absolutely safe, you'll want to include some limits on recursive processing. It's possible to have loops in the file system with symbolic links and such (especially in LINUX/UNIX, but third party tools can enable this in Windows as well).
To make sure you don't get into a loop when dealing with symbolic links, use the File.getCanonicalPath methods to get the "real" path for the directory and keep track of all visited canonical paths. You could also use getCanonicalFile and keep track of all the files, but that's probably not needed unless you really want to avoid the occasional instance where you'll process the same file twice.
You can use the File object to determine whether you are looking at a file or a directory:
File file = new File("/"); //root
Then as you are recursing (or iterating depending on your preference) you have a simple check:
if(tempFile.isDirectory())
//do recursive call on that directory
else
//perform check on file name
Also not forget exceptions in recursive processing. Some folders may not be accessible due to access right restrictions. Also, the Windows system folder "System Volume Information" cannot be entered in Windows Explorer, so I suppose it will throw an exception if you try to get inside programmaticaly.
You can use a recursive call through the entire file system: You can use the following methods of java.io.File:
listRoots(): list the root files (In Windows it's the drives, on Mac OS X and linux it's '/').
listFiles(): list the enclosing files of a directory