Linux Api has O_TMPFILE flag to be specified with open system call creating unnamed temporary file which cannot be opened by any path. So we can use this to write data to the file "atmoically" and the linkat the given file to the real path. According to the open man page it can be implemented as simple as
char path[1000];
int fd = open("/tmp", O_TMPFILE | O_WRONLY, S_IWUSR);
write(fd, "123456", sizeof("123456"));
sprintf(path, "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/tmp/1111111", AT_SYMLINK_FOLLOW);
Is there a Java alternative (probably non crossplatform) to do atomic write to a file without writing Linux-specific JNI function? Files.createTempFile does completely different thing.
By atomic write I mean that either it cannot be opened and be read from or it contains all the data required to be writted.
I don't believe Java has an API for this, and it seems to depend on both the OS and filesystem having support, so JNI might be the only way, and even then only on Linux.
I did a quick search for what Cygwin does, seems to be a bit of a hack just to make software work, creating a file with a random name then excluding it only from their own directory listing.
I believe the closest you can get in plain Java is to create a file in some other location (kinda like a /proc/self/fd/... equivalent), and then when you are done writing it, either move it or symbolic link it from the final location. To move the file, you want it on the same filesystem partition so the file contents don't actually need to be copied. Programs watching for the file in say /tmp/ wouldn't see it until the move or sym link creation.
You could possibly play around with user accounts and filesystem permissions to ensure that no other (non SYSTEM/root) program can see the file initially even if they tried to look wherever you hid it.
Related
Locker Apps is a Folder Lock application, how can I lock files or folders on Windows using Java?
Here is what I tried:
File file = new File(file path);
file.setExecutable(false);
file.setWritable(false);
file.setReadable(false);
But only file.setwritable(false); works - I can't rewrite the file. Other methods do nothing to the file.
These methods are simply setting the file system access permissions for the file. In order to understand them, you need to understand the OS / file system access control rules.
For example, on Linux file.setWriteable(false) is equivalent to running chmod u-w file to clear the "owner write" access bit:
Note:
chmod can only change any permissions on the file if you are the owner of the file, or if you are running as root.
The owner write permission means that owner (or root) can execute the file, or not. If you are neither, then that permission does not affect you.
So there are at least two possible reasons why setWriteable may not be "working".
You are not executing your Java program as the file owner or root. In that case, setWriteable will return false. But note that you don't check the result!
You are not trying to write the file as the file's owner. In that case, the access but you just removed (in Java) does not affect you.
Solutions:
There is a newer / better API for setting file permissions in Java in the java.nio.file.Files class:
public static Path setPosixFilePermissions(
Path path,
Set<PosixFilePermission> perms)
throws IOException
This allows you to set / clear all avail POSIX file permissions in one call, and it with throw an exception if it can't for any reason.
Many file systems also support more sophisticated ACL mechanisms ....
HOWEVER
None of this is equivalent to the functionality provided by a File Locker app. Why? Because any attempt to block file access via file permissions or ACLs can trivially be reversed by someone with root access. Provided you know what it is doing at a technical level.
What the Windows "Folder Lock" app can apparently encrypt files or hide them. Files can be marked as hidden natively in Java 7 and later by setting the "dos:hidden" attribute; see https://stackoverflow.com/a/42816082/139985. It is probably also using permissions and ACLs to restrict access, that can be doing on Java too. It may also be doing other things. The documentation says (unhelpfully!):
Once the files are locked, it becomes protected in every possible way and can only be accessed through the Folder Lock security application.
That sounds like marketing rather than truth, and is almost certainly untrue. However figuring out what the app is actually doing, would require me to get a Windows machine, download and install the software, and then violate the license by attempting to reverse engineer it.
But note that the above method for "hiding" is Windows specific. On Linux / Mac OS you "hide" a file from some commands by making the first character of the file name a dot (".") character.
I'm trying to use Java WatchEvent ENTRY_MODIFY to check if a file is being access (ie: read, copied to clipboard). However from the documentation and a small test case I've made, that event isn't being fired. It's only fired when the file is changed.
Am I doing something wrong? If so, how can I monitor a file on the filesystem?
This isn't directly built into java. Your best bet is to jump into a native OS solution. This can be tedious if you want to support multiple systems though.
If you can get away with supporting windows take a look at THIS LINK . Scroll down to the bottom and look at similar apps. You would be interested in any app that contains a command line interface. What you will need to do is install one of the software and then kick off a process using Runtime.exec. You could potentially just use a direct dll, but I'm not qualified to tell you which dll will give you that information or if it even exists. It might be something you want to look into though if you do not want a 3rd party dependency.
You will read the results of the process that hooks into the windows dll's and will tell you if the file is currently open (See this link for more details). Your application will have to pull data (consistently asking the Application if the file is open). It is not ideal, but probably it is a potential solution.
Answering from your definition of file being accessed (copied and being read), however for file alteration there are several existing API available. Here is an example given to monitor file alteration.
To check file is copied to clipboard, you can use Clipboard#hasFiles() method when content of clipboard modified. If it returns true than file is copied to clipboard.
To check file is being read currently, you can check if the file is locked or not using implementation of FileLock abstract class. It has acquiredBy() method which returns the channel currently holding the lock on file.
you can try other libraries to accomplish that task, for example http://jnotify.sourceforge.net/
or http://java.dzone.com/announcements/new-java-library-monitor-file the latter specifically stands: File Access Monitoring- You will be able to receive notifications about events when access or modification date is changed.
I am sure this is a relatively simple question, and I actually think it may be more of a problem with Windows than with Java.
I have a method for copying a file to a new directory, which takes two File objects, a File created with the path of the original, and a File created with the desired path of the copy. I am sure that the method works because I have used it to successfully copy a file onto my Desktop.
However, using my actual desired path creates an error:
java.io.FileNotFoundException: PATH (The system cannot find the path
specified)
Where the PATH is the path that I am attempting to use.
Here is my guess:
I am making this program for use on another machine. As such, the path that I am trying to use is:
C:\Users\XXXXXX\rest_of_path\filename.file
where XXXXXX is the primary user on the machine which I am writing the program for.
This directory exists on my system, but XXXXXX is not a user on my system. So I am guessing that Windows is causing a problem because of that.
I'm now changing my code to use a solution which depends on the machine, and is not hardcoded (System.getProperty).
However, I'd really like to know why this problem is occurring, from an academic standpoint, as a Windows and Java user.
Thanks in advance.
EDIT: accidentally used forward slashes when I meant double backslashes. To ensure that it was not a spelling error, I simply copied the directory using windows, and pasted it into my program (then doubled up on the backslashes).
EDIT: several users have suggested something which is far more clean than what I am trying to do in the first place. I'm leaving this question open because I'm curious why it is not working.
EDIT: I used the solution above and I'm completely happy with it. I still don't know why Windows will not allow me to access the original path, but I guess I really don't care at this point. Thanks, everybody!
In java, and generally most programming languages, you don't always have to provide the exact directory of your file. Although it would be nice to see the code you're using to get the file, I'll provide how it can be done.
I'm assuming you aren't using new File("file.txt") because that retrieves files from the folder your program is in, and doesn't require an entire address like C:\...\...\.... You certainly don't want to use an entire address because different operating systems use different paths, obviously.
The best you can do is put your files and requested folders somewhere relative to your program is (whether it's class files or a .jar file).
But with Windows you can be sure that with System.getProperty("...") you can retrieve directory URLs as relative paths for your files/folders.
Documentation on System.getProperty here: http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
I may not have helped or answered your question at all. But hopefully you'll find a solution.
Is there any way in Java to write out to a temporary file securely?
As far as I can tell, the only way to create a temporary file (createTempFile) does't actually open it at the same time, so there's a race condition between file open & file write. Am I missing something? I couldn't find the C source code behind createFileExclusively(String) in UnixFileSystem.java, but I doubt it can really do anything since the file open occurs in the Java code after the temp file is created (unless it tries to do something with file locks?).
The problem
Between when the temporary file is created & you open it, a malicious attacker could unlink that temporary file & put malicious stuff there. For example, an attacker could create a named pipe to read sensitive data. Or similarly if you eventually copy the file by reading it, then the named pipe could just ignore everything written & supply malicious content to be read.
I remember reading of numerous examples of temporary file attacks in the past 10+ years that exploit the race condition between when the name appears in the namespace and when the file is actually opened.
Hopefully a mitigating factor is that Java set's the umask correctly so a less-privileged user can't read/write to the file and typically the /tmp directory restricts permissions properly so that you can't perform an unlink attack.
Of course if you pass a custom directory for the temporary file that's owned by a less-privileged user who's compromised, the user could do an unlink attack against you. Hell, with inotify, it's probably even easier to exploit the race condition than just a brute force loop that does a directory listing.
http://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/
Java
use java.io.File.createTempFile() – some interesting info at http://www.veracode.com/blog/2009/01/how-boring-flaws-become-interesting/
for directories there is a helpful posting at How to create a temporary directory/folder in Java?
Java 7
for files use java.io.File.createTempFile()
for directories use createTempDirectory()
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html
Since Java 7 we have OpenOption.
An object that configures how to open or create a file.
Objects of this type are used by methods such as newOutputStream, newByteChannel, FileChannel.open, and AsynchronousFileChannel.open when opening or creating a file.
Of particular interest is StandardOpenOptions.CREATE_NEW.
Create a new file, failing if the file already exists. The check for the existence of the file and the creation of the file if it does not exist is atomic with respect to other file system operations.
So, you can do something like this:
FileChannel mkstemp() {
Path path = Files.createTempFile(null, null);
Files.delete(path);
return FileChannel.open(path, WRITE, CREATE_NEW);
}
Implementing the same template behaviour is left as exercise to the reader.
Keep in mind that on many systems, just because a file doesn't have a name doesn't at all mean it's inaccessible. For example, on Linux open file descriptors are available in /proc/<pid>/fd/<fdno>. So you should make sure that your use of temporary files is secure even if someone knows / has a reference to the open file.
You might get a more useful answer if you specify exactly what classes of attacks you are trying to prevent.
Secure against other ordinary userid's? Yes, on any properly functioning multi-user system.
Secure against the your own userid or the superuser? No.
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