Page History

Files on multiuser systems are generally owned by a particular user. The owner of the file can determine which other users on the system should be allowed to access the contents of these files.
These filesystems generally use a privileges and permissions model to protect file access. When a file is created, the access permissions of the file immediately dictate who may access or operate on the file. If a program creates a file with insufficiently restrictive access permissions, an attacker may read or modify the file before the program can modify the permissions. Consequently, files must be created with access permissions that prevent unauthorized file access.

Java provides several methods for creating files. Additionally, several classes, such as FileOutputStream can create files in their constructors. Prior to Java 1.7, these methods were unable to specify access permissions when creating files. In these cases, the problem of ensuring the file is created with adequate permissions falls outside the program and must be managed by anyone executing the program.

The Java 1.7 new I/O facility (java.nio) provides classes for managing file access permissions. Additionally, many of the methods and constructors that create files accept an argument allowing the program to specify the initial file permissions.

Noncompliant Code Example

The constructors for FileOutputStream and FileWriter do not allow the programmer to explicitly specify file access permissions. This applies to Java 1. 7, as well as previous versions of Java.

In this noncompliant code example, if the constructor creates a new file, which is accessible by untrusted users, the access permissions are the access permissions of any file created isimplementation-defined, and are likely to grant untrusted users the ability to read or modify the filemay fail to prevent unathorized access.

Writer out = new FileWriter("file");

Implementation Details (POSIX)

...

Compliant Solution

Since Java 1.6 and earlier provide no mechanism for specifying default permissions upon file creationscreation. Consequently, the problem must be solved outside of the Java program. This can be accomplished avoided or solved using some mechanism external to Java, such as by using native code and JNI. In POSIX, it can also be done by allowing the Java program to be invoked only via a batch script that set a sufficiently restrictive umask.

Compliant Solution (Java 1.7, POSIX)

The Java 1.7 new I/O facility (java.nio) provides classes for managing file access permissions. Additionally, many of the methods and constructors that create files accept an argument allowing the program to specify the initial file permissions.

The Files.newByteChannel() method allows a file to be created with specific permissions. This method is platform-independent, but the actual permissions are platform-specific. The following compliant solution illustrates sufficiently restrictive permissions for POSIX platforms.

Path file = new File("file").toPath();

// Throw exception rather than overwrite existing file
Set<OpenOption> options = new HashSet<OpenOption>();
options.add(StandardOpenOption.CREATE_NEW);
options.add(StandardOpenOption.APPEND);

// File permissions should be that only user may read/write file
Set<PosixFilePermission> perms = PosixFilePermissions.fromString("rw-------");
FileAttribute<Set<PosixFilePermission>> attr = PosixFilePermissions.asFileAttribute(perms);

try (SeekableByteChannel sbc = Files.newByteChannel(file, options, attr)) {
  // write data
};

Compliant Solution (Java 1.7, Windows)

Java provides no Windows analog of PosixFilePermissions.

AclFileAttributeView – Supports reading or updating a file's Access Control Lists (ACL). The NFSv4 ACL model is supported. Any ACL model, such as the Windows ACL model, that has a well-defined mapping to the NFSv4 model might also be supported.

Exceptions

FIO03-EX0: If a file is created inside a directory that is both secure and unreadable by untrusted users, then that file may be created with the default access permissions. See FIO07-J. Do not create temporary files in shared directories for the definition of a secure directory. This could be the case if, for example, the entire filesystem is trusted, or is accessible only to trusted users.

...

...