During an installation process I need to check if a userprovided path is writable to a specified user.
The Path (A UNC Path like \fileserver\share) may not be writable to the user, who is executing the Setup.exe (It's a Windows-Only Software), so I think How do you check for permissions to write to a directory or file? may not work for me.
I know in Java7 there will be a new Filesystem-API, but Java7 is not released yet.
EDIT:
User 1 - runs the installer
User 2 - runs the installed application
If user 1 get an error "Permission denied" I still don't know, about user 2. I need to check the permission for an other useraccount during the process of installation.
I may use net use /user:<user2> <passwd2> but I'm not sure, if I get all information I need. I get the information, that the path exists, but not, if User 2 is allowed to write.
before java 7, you don't have standard way to check if a user can write to a java file using standard library. this is because the old java io just is not power enough.
for example, File.canWrite() will not work if consider file owner, etc....
what you can do is check it in directly, for example, try to write a empty line to it. (this need to consider you application,if your application just don't care a blank line at end and auto delete ending blank lines , then it works..... this is just an example, you can get many tricky ways considering your applicaton.
Related
I am trying to programatically purge log files from a running(!) system consisting of several Java and non-Java servers. I used Java's File.delete() operation and it usually works fine. I am also perfectly fine with log files that are currently in use not being deleted, so I just log it as a warning whenever File.delete() returns false.
However, in log files which are currently still being written to by NON-Java applications (Postgres, Apache HTTPD etc., Java applications might also be affected, but I didn't notice yet, and all are using the same logging framework anyway, which seems to be OK) are not actually deleted (which is what I expected), however, File.delete() returns "true" for them.
But not only do these files still exist on the file system (Windows explorer and "dir" still show them), but afterwards they are inaccessible... when I try to open them with a text editor etc. I get "access denied" or similar error messages, when I try to copy them with explorer, it also claims that I do not have permissions, when I check its "properties" with explorer, it gives me "You do not have permission to view or edit this object's permissions".
Just to be clear: before I ran the File.delete() operation, I could access or delete these files without any problems, the delete operation "breaks" them. Once I stop the application, the file then disappears, and on restart, the application creates it from scratch and everything is back to normal.
The problem is that when NOT restarting the application after the log file purge operation, the application logs to nirvana.
This behavior reminds me a bit of the file deletion behavior of Linux: if you delete a file that is still held open by an application, it disappears from the file system, but the application - still holding a file handle - will happily continue writing to that file, but you will never be able to access it afterwards. The only difference being that here the files are still visible in the FS, but also not accessible otherwise.
I should mention that both my Java program and the applications themselves are running with "system" user.
I also tried Files.delete(), which allegedly throws an IOException indicating the error... but it seems there is no error.
What I tried to work around the problem is to check if the files are currently locked, using the method described here https://stackoverflow.com/a/1390669/5837050, but this only works for some of the files, not for all of them.
I basically need a reliable way (at least for Windows, if it worked also for Linux, that would be great) to determine if a file is still being used by some program, so I could just not delete it.
Any hints appreciated.
I haven't reproduced it but it seems like an OS expected behaviour, normally different applications run with different users which have ownership on this type of files but I understand that you want like a master purge Java which checks the log files not in use to delete them (running with enough grants of course).
So, considering that the OS behaviour is not going to change I would suggest to configure your logs with "roll file appender" policies and then check the files that match these policies.
Check the rollback policies for logback to make you an idea:
http://logback.qos.ch/manual/appenders.html#onRollingPolicies
For example, if your appender file policy is "more than one day or more than 1Gb" then just delete files which last edition date are older than one day or size are 1Gb. With this rule you will be sure to delete log files that are not in use.
Note that.. with a proper rolling policy maybe you even don't need your purge method, look at this configuration example:
<!-- keep 30 days' worth of history capped at 3GB total size -->
<maxHistory>30</maxHistory>
<totalSizeCap>3GB</totalSizeCap>
I hope this could help you a bit!!
Getting An "Access Denied" Error While Editing "Hosts" File Through Java Program.
Program needs an ADMINISTRATIVE PRIVILEGE To Edit The Hosts File.
So Is there any Solution To provide That Administrative privilege to java program so that It can edit Hosts File.
** Note **
I am Using Window 8.1 OS.
Hosts File Location is:
C:\Windows\System32\Drivers\etc\Hosts
Have a look at the AccessController API: Java Access Controller
one thing is for sure though, when the user runs the Java program, the user must right-click and select 'Run As Administrator'.
Another option is that you could read in the file, make your changes in memory, (file could be read in as a string), and then write out the file to replace the HOSTS file. Which again, you definitely need Administrator privileges.
Quick Google search also showed source code for a package that let's you edit hosts file, you might want to take a look at that. It still definitely needs the administrator permissions though. Link here
Have a look at this previous SO question, it might give you a few ideas.
The main issue with writing this kind of programs is the permissions. The Hosts file is a critical part of every operating system, and it's only logically to have layers of security around it to prevent any random program from changing the hosts file, hence all these extra hurdles.
I am developing a java web application that needs to pass shell scripts to putty after user authentication. putty.exe should launch only if authentication is successful and if the script has begun running successfully.
Also, since different users might have installed putty in different locations on their systems. Is there any way to launch putty.exe without requiring the user to manually configure the path. Or is it possible to programmatically find the path and launch putty?
I will start by saying not having the user add putty to the path is most easily solved by creating a configuration file for each user, where one of the parameters will be the location of the putty executable. Properly handling this with default values and a dialogue box if putty can't be opened would be simple and familiar to most users.
Two simple situations could completely mess with how you do a search for the executable: the user renames the putty executable or the user has multiple versions of putty.
To avoid getting stumped by the first situation you are going to have to ask for the new name and somehow save it in a config.
To avoid getting stumped by the second you are going to have to ask for the version of putty they want, store that version, and somehow do version checking if all you want to do is look for putty.exe (maybe you have a file of the checksum for each version).
This is just as, if not more annoying to the user (and definitely more annoying to you) than just asking them to point to the executable. There are more ways that things could go wrong, as well.
Basically, it is possible to search for the executable but it would not save anyone any trouble and would only make more for you. Having the user configure the path is not very tricky, but if you want to avoid it then the easiest thing is to have per-user configuration files with the putty path saved in it by your program.
One way is by editing the PATH system variable of the user machines and add the full path of the Putty.exe location.
Another solution is to create a link that points to Putty.exe in a default folder in every user machine, so Java could access to this link w/o problems.
A third solution could be to ship the Putty.exe with your application installer. Putty.exe doesn't need custom DLLs to work (at least I haven't needed one yet).
Theoritically it is possible if you search through every directory on user's computer to find putty.exe. But practically, you should required the file to be put in some familiar directories or use an environment variable.
I agree with people above. Also in your application you can provide ability to user set putty.exe full path and store them in cookies.
I want check whether a logged in user has permissions like "write" or "Read and Execute" for a folder that the user is using as destination for an installation.
Basically I am using the InstallAnyWhere to prepare the installer. I want the installer to check the given destination has the above permissions for the loggedin user or not, if the user does not have these permission the installer should throw a warning message.
I need this to be done using java. Is there a way to check this using java?
File dir = new File("/path/to/dir");
dir.canRead();
dir.canWrite();
...
If you are using Java 7 there is a new way to get file attributes. I am assuming that you are on Unix based OS (since you are talking about write and execute permissions on a directory).
The method you can use is Files.getAttribute(Path, String, LinkOption...). In your case it should return PosixFileAttributeView.
You can find more details at the Managing Metadata section of the Java NIO tutorial.
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.