...
| Code Block | ||
|---|---|---|
| ||
class TempFile{
public static void main(String[] args) throws IOException{
File f = new File(""tempnam.tmp"");
FileOutputStream fop = new FileOutputStream(f);
String str = "Data""Data";
if(f.exists()){
fop.write(str.getBytes());
} else {
System.out.println(""This file does not exist"");
}
}
}
|
Additionally, the output stream has not been closed after use which violates FIO32-J. Ensure all resources are properly closed when they are no longer needed. Finally, the file is not deleted after use.
...
A shared lock is useful when a file is to be read concurrently from multiple processes whereas an exclusive lock is more useful for writing. File locks cannot be used with threads within a single process. Both shared locks and exclusive locks eliminate the potential for a race condition on the locked region. The exclusive lock is similar to a mutual exclusion solution, and the shared lock eliminates race conditions by removing the potential for altering the state of the locked file region (one of the required properties for a data race).
| Wiki Markup |
|---|
""Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and consequently unspecified"" \[[API 06|AA. Java References#API 06]\]. Microsoft Windows uses a file-locking mechanism called mandatory locking because every process attempting access to a locked file region is subject to the restriction. Linux implements mandatory locks and advisory locks. An advisory lock is not enforced by the operating system, which severely diminishes its value from a security perspective. Unfortunately, the mandatory file lock in Linux is also largely impractical for the following reasons: |
...
| Code Block | ||
|---|---|---|
| ||
class TempFile{
public static void main(String[] args) throws IOException{
File f = File.createTempFile("tempnam",".tmp""tempnam",".tmp");
FileOutputStream fop = new FileOutputStream(f);
String str = "Data""Data";
try {
fop.write(str.getBytes());
fop.flush();
}finally {
// Stream/file is not closed first, file will not be deleted
f.deleteOnExit(); // Delete the file when the JVM terminates
}
}
}
|
...
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
This rule appears in the C Secure Coding Standard as FIO43-C. Do not create temporary files in shared directories.
...
| Wiki Markup |
|---|
\[[API 06|AA. Java References#API 06]\] Class File, methods {{createTempFile}}, {{delete}}, {{deleteOnExit}}
\[[Darwin 04|AA. Java References#Darwin 04]\] 11.5 Creating a Transient File
\[[SDN 08|AA. Java References#SDN 08]\] Bug IDs: 4171239, 4405521, 4635827, 4631820
\[[Secunia 08|AA. Java References#Secunia 08]\] [Secunia Advisory 20132|http://secunia.com/advisories/20132/]
\[[CVE 08|AA. Java References#CVE 08]\] [CVE-2008-5354|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5354]
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 459 |http://cwe.mitre.org/data/definitions/459.html] ""Incomplete Cleanup"", [CWE ID 377|http://cwe.mitre.org/data/definitions/377.html] ""Insecure Temporary File"" |
...
FIO33-J. Exclude user input from format strings 09. Input Output (FIO) FIO36-J. Do not create multiple buffered wrappers on an InputStream