CVE-2020-8908: Files::createTempDir local information disclosure vulnerability

[JLLeitschuh]

IMPORTANT NOTE

Updating to Guava 30.0 does not fix this security vulnerability. The method is merely deprecated. There currently exits no fix for this vulnerability.

https://github.com/google/guava/issues/4011#issuecomment-765672282

---

Since the fix for this vulnerability is now disclosed by this commit (https://github.com/google/guava/commit/fec0dbc4634006a6162cfd4d0d09c962073ddf40) and it was closed internally by google as 'Intended Functionality' I figure I'll disclose the vulnerability fully.

Vulnerability

File guavaTempDir = com.google.common.io.Files.createTempDir();
System.out.println("Guava Temp Dir: " + guavaTempDir.getName());
runLS(guavaTempDir.getParentFile(), guavaTempDir); // Prints the file permissions -> drwxr-xr-x
File child = new File(guavaTempDir, "guava-child.txt");
child.createNewFile();
runLS(guavaTempDir, child); // Prints the file permissions -> -rw-r--r--

On the flip side, when using java.nio.file.Files, this creates a directory with the correct file permissions.

Path temp = Files.createTempDirectory("random-directory");
System.out.println("Files Temp Dir: " + temp.getFileName());
runLS(temp.toFile().getParentFile(), temp.toFile()); // Prints the file permissions -> drwx------
Path child = temp.resolve("jdk-child.txt");
child.toFile().createNewFile();
runLS(temp.toFile(), child.toFile()); // Prints the file permissions -> -rw-r--r--

Impact

The impact of this vulnerability is that, the file permissions on the file created by com.google.common.io.Files.createTempDir allows an attacker running a malicious program co-resident on the same machine can steal secrets stored in this directory. This is because by default on unix-like operating systems the /temp directory is shared between all users, so if the correct file permissions aren't set by the directory/file creator, the file becomes readable by all other users on that system.

Workaround

This vulnerability can be fixed by explicitly setting the java.io.tmpdir system property to a "safe" directory when starting the JVM.

Resolution

The resolution by the Google team was the following:

The team decided to document the behavior, as well as deprecate the method as other alternatives exist.

This completely makes sense to me, and I think is appropriate. The open question that exists in my mind is whether or not this issue warrants a CVE number issued.

[melloware]

Yuck this code is being reported as a security vulnerability by Sonatype IQ Server as SONATYPE-2020-0926.

RECOMMENDATION There is no non-vulnerable upgrade path for this component/package. We recommend investigating alternative components or replacing all usages of the deprecated Files.createTempDir() method with a safer alternative, such as java.nio.file.Files.createTempDirectory() for Java 7+.

I know its deprecated by why not just rip this code out?

It will be forever reported as a vulnerability by apps like OWASP and Sonatype.

[JLLeitschuh]

Can someone from Google make an official statement on whether or not this issue will receive a CVE number or not?

[melloware]

And leaving the deprecated there is OK so people have Javadoc on alternatives but shouldn't it throw UnsupportedOperationException instead of just leaving this vulnerable code in here for someone to use?

[JLLeitschuh]

@melloware, this is indeed a security vulnerability, however, given that the severity of this vulnerability is quite low, I think that the way that Google and the Guava team has handled this vulnerability with a documented depreciation is appropriate.

It's important to note that the JDK actually contains a method with a very similar vulnerability. You'll notice that the documentation on File.createTempFile method changed between Java 6 and Java 7.

• https://docs.oracle.com/javase/6/docs/api/java/io/File.html#createTempFile(java.lang.String,%20java.lang.String)
• https://docs.oracle.com/javase/7/docs/api/java/io/File.html#createTempFile(java.lang.String,%20java.lang.String)

This new line of documentation reads:

The Files.createTempFile method provides an alternative method to create an empty file in the temporary-file directory. Files created by that method may have more restrictive access permissions to files created by this method and so may be more suited to security-sensitive applications.

[melloware]

I understand but its listed in Sonatype with a score of 7 which means my management team freaks out we are using a JAR with a vulnerability. Even if you prove to management you aren't using that feature it doesn't mean someone tomorrow in the org couldn't accidentally start using it. So that is why I am PRO on removal vs documentation.

When you work at a very security sensitive client who receives daily reports that include this type of alert.

[JLLeitschuh]

A few options for you.

1. Push back on Sonatype's analysis of this vulnerability. As a customer, if you think that your security vendor's analysis of a given vulnerability is rating the vuln as too high, then push back. Feel free to include me in the email thread. My email address can be found on my GitHub profile.
2. Push back on management. Here's an ArchUnit test that you can add into your JUnit or TestNG tests that will verify that this method isn't used anywhere, thus preventing its from being used by someone tomorrow.

https://github.com/TNG/ArchUnit

@ArchTest
public static final ArchRule forbid_calls_to_guava_Files_createTempDir =
    classes()
        .should(not(callMethod(com.google.common.io.Files.class, "createTempDir")))
        .because("Files::createTempDir contains a local information disclosure vulnerability (https://github.com/google/guava/issues/4011)");

[melloware]

Cool I didn't know about ArchUnit!!! It won't help much we have over 50 in production applications using it so we would have to add this test to each one and all future applications.

As for your email when I click on your profile GitHub gives me the "Unicorn page is taking too long to load!"??? you must have a lot in your profile.

[JLLeitschuh]

It won't help much we have over 50 in production applications using it so we would have to add this test to each one and all future applications.

Agreed.

A few suggestions for you:

1. Create one Gradle build that pulls down all of the JAR artifacts from your different applications, load them all onto the classpath of that Gradle build, and run the check there. Sounds complicated, but it may not be if you publish all your jars to the same internal Sonatype instance.
2. Something that may scale better is GitHub's Code Scanning feature. I'm a OSS Security researcher that contributes to the GitHub Security Lab Bug Bounty program. Your question here actually inspired me to finally write the queries below for my GitHub Security Lab Bug Bounty submission.

The following two CodeQL queries would find all instances of this vulnerability across your codebases.

TempDirsUtil.qll (This is a utility the two queries below depend upon)

import java
import semmle.code.java.dataflow.FlowSources

class MethodAccessSystemGetProperty extends MethodAccess {
  MethodAccessSystemGetProperty() {
    getMethod() instanceof MethodSystemGetProperty
  }

  predicate hasPropertyName(string propertyName) {
    this.getArgument(0).(CompileTimeConstantExpr).getStringValue() = propertyName
  }
}

class MethodAccessSystemGetPropertyTempDir extends MethodAccessSystemGetProperty {
  MethodAccessSystemGetPropertyTempDir() { this.hasPropertyName("java.io.tmpdir") }
}

/**
 * Find dataflow from the temp directory system property to the `File` constructor.
 * Examples:
 *  - `new File(System.getProperty("java.io.tmpdir"))`
 *  - `new File(new File(System.getProperty("java.io.tmpdir")), "/child")`
 */
private predicate isTaintedFileCreation(Expr expSource, Expr exprDest) {
  exists(ConstructorCall construtorCall |
    construtorCall.getConstructedType() instanceof TypeFile and
    construtorCall.getArgument(0) = expSource and
    construtorCall = exprDest
  )
}

private class TaintFollowingFileMethod extends Method {
  TaintFollowingFileMethod() {
    getDeclaringType() instanceof TypeFile and
    (
      hasName("getAbsoluteFile") or
      hasName("getCanonicalFile")
    )
  }
}

private predicate isTaintFollowingFileTransformation(Expr expSource, Expr exprDest) {
  exists(MethodAccess fileMethodAccess |
    fileMethodAccess.getMethod() instanceof TaintFollowingFileMethod and
    fileMethodAccess.getQualifier() = expSource and
    fileMethodAccess = exprDest
  )
}

predicate isAdditionalFileTaintStep(DataFlow::Node node1, DataFlow::Node node2) {
  isTaintedFileCreation(node1.asExpr(), node2.asExpr()) or
  isTaintFollowingFileTransformation(node1.asExpr(), node2.asExpr())
}

Query 1

Finds

/**
 * @name Temporary Directory Local information disclosure
 * @description Detect local information disclosure via the java temporary directory
 * @kind problem
 * @problem.severity warning
 * @precision very-high
 * @id java/local-information-disclosure
 * @tags security
 *       external/cwe/cwe-200
 */

import TempDirUtils

/**
 * All `java.io.File::createTempFile` methods.
 */
class MethodFileCreateTempFile extends Method {
  MethodFileCreateTempFile() {
    this.getDeclaringType() instanceof TypeFile and
    this.hasName("createTempFile")
  }
}

class TempDirSystemGetPropertyToAnyConfig extends TaintTracking::Configuration {
  TempDirSystemGetPropertyToAnyConfig() { this = "TempDirSystemGetPropertyToAnyConfig" }

  override predicate isSource(DataFlow::Node source) {
    source.asExpr() instanceof MethodAccessSystemGetPropertyTempDir
  }

  override predicate isSink(DataFlow::Node source) { any() }

  override predicate isAdditionalTaintStep(DataFlow::Node node1, DataFlow::Node node2) {
    isAdditionalFileTaintStep(node1, node2)
  }
}

abstract class MethodAccessInsecureFileCreation extends MethodAccess { }

/**
 * Insecure calls to `java.io.File::createTempFile`.
 */
class MethodAccessInsecureFileCreateTempFile extends MethodAccessInsecureFileCreation {
  MethodAccessInsecureFileCreateTempFile() {
    this.getMethod() instanceof MethodFileCreateTempFile and
    (
      this.getNumArgument() = 2 or
      getArgument(2) instanceof NullLiteral or
      // There exists a flow from the 'java.io.tmpdir' system property to this argument
      exists(TempDirSystemGetPropertyToAnyConfig config |
        config.hasFlowTo(DataFlow::exprNode(getArgument(2)))
      )
    )
  }
}

class MethodGuavaFilesCreateTempFile extends Method {
  MethodGuavaFilesCreateTempFile() {
    getDeclaringType().hasQualifiedName("com.google.common.io", "Files") and
    hasName("createTempDir")
  }
}

class MethodAccessInsecureGuavaFilesCreateTempFile extends MethodAccessInsecureFileCreation {
  MethodAccessInsecureGuavaFilesCreateTempFile() {
    getMethod() instanceof MethodGuavaFilesCreateTempFile
  }
}
from MethodAccessInsecureFileCreation methodAccess
select methodAccess,
  "Local information disclosure vulnerability due to use of file or directory readable by other local users."

Example of this query finding vulns against other Google projects: https://lgtm.com/query/7917272935407723538/

The above query will find method calls like this:

File.createTempFile("biz", "baz", null); // Flagged vulnerable
File.createTempFile("biz", "baz"); // Flagged vulnerable
com.google.common.io.Files.createTempDir(); // Flagged vulnerable
File tempDirChild = new File(new File(System.getProperty("java.io.tmpdir")), "/child"); // Not Flagged
File.createTempFile("random", "file", tempDirChild); // Flagged vulnerable

Query 2:

/**
 * @name Temporary Directory Local information disclosure
 * @description Detect local information disclosure via the java temporary directory
 * @kind path-problem
 * @problem.severity warning
 * @precision very-high
 * @id java/local-information-disclosure
 * @tags security
 *       external/cwe/cwe-200
 */

import TempDirUtils
import DataFlow::PathGraph

private class MethodFileSystemCreation extends Method {
  MethodFileSystemCreation() {
    getDeclaringType() instanceof TypeFile and
    (
      hasName("mkdir") or
      hasName("createNewFile")
    )
  }
}

private class TempDirSystemGetPropertyToCreateConfig extends TaintTracking::Configuration {
  TempDirSystemGetPropertyToCreateConfig() { this = "TempDirSystemGetPropertyToAnyConfig" }

  override predicate isSource(DataFlow::Node source) {
    source.asExpr() instanceof MethodAccessSystemGetPropertyTempDir
  }

  override predicate isSink(DataFlow::Node sink) {
    exists (MethodAccess ma |
      ma.getMethod() instanceof MethodFileSystemCreation and
      ma.getQualifier() = sink.asExpr()
    )
  }

  override predicate isAdditionalTaintStep(DataFlow::Node node1, DataFlow::Node node2) {
    isAdditionalFileTaintStep(node1, node2)
  }
}


from DataFlow::PathNode source, DataFlow::PathNode sink, TempDirSystemGetPropertyToCreateConfig conf
where conf.hasFlowPath(source, sink)
select source.getNode(), source, sink,
  "Local information disclosure vulnerability from $@ due to use of file or directory readable by other local users.", source.getNode(),
  "system temp directory"

Example of this query finding vulns against other Google projects: https://lgtm.com/query/548722881855915017/

The above query will find instances of this vulnerability by doing dataflow analysis to find where uses of the system property flow to a file creation location.

File tempDirChild = new File(System.getProperty("java.io.tmpdir"), "/child"); // Not flagged
tempDirChild.mkdir(); // Flagged vulnerable
tempDirChild.createNewFile(); // Flagged vulnerable

With the GitHub Code Scanning feature, once my queries are merged, you'll automatically get alerts about these vulnerabilities in your code. The pull request can be found here: https://github.com/github/codeql/pull/4388

---

As for your email when I click on your profile GitHub gives me the "Unicorn page is taking too long to load!"??? you must have a lot in your profile.

You sometimes have to reload a few times. I have over 1,596 forks against my profile. I have a bot that I use to automate the generation of thousands of security-fix pull requests across GitHub projects. The first project I did this for, I forked all the projects under my personal account, I have since learned this is a mistake 😆 . Legit, do not do this. GitHub doesn't scale well to having this many forks bound to your account. The second project, where I generated 3,880 pull requests, I realized that it was better for the health of my account if I forked them under organizations instead. I ended up creating 45 GitHub organizations for that project.

• https://github.com/BulkSecurityGeneratorProject
• https://github.com/BulkSecurityGeneratorProject1
• https://github.com/BulkSecurityGeneratorProject2
• ...
• https://github.com/BulkSecurityGeneratorProject45

[melloware]

@JLLeitschuh Than you for all your work! That GitHub bot code will be a huge help!

[semmalimayan]

@JLLeitschuh does the com.google.common.io.Files.createParentDirs() creates with similar vulnerable permissions ?

[JLLeitschuh]

@semmalimayan here's the method you're asking about.

https://github.com/google/guava/blob/fec0dbc4634006a6162cfd4d0d09c962073ddf40/guava/src/com/google/common/io/Files.java#L470-L487

The true answer here is "it depends".

For example, this would be vulnerable:

File tempDirChild = new File(System.getProperty("java.io.tmpdir"), "/child/text_file.txt");
com.google.common.io.Files.createParentDirs(tempDirChild); // Anything in the 'child' directory would have a local information disclosure vulnerability 
tempDirChild.createNewFile(); // This file would be visible to other users, putting sensitive information in this file would be an information disclosure vulnerability.

That being said, I think that at that point, this is probably more likely a user-error vulnerability, less a guava vulnerability.

[JLLeitschuh]

A similar vulnerability has been disclosed and patched in JUnit 4. CVE pending.

https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp

To reiterate my earlier question:

Can someone from Google make an official statement on whether or not this issue will receive a CVE number or not?

CC: @google-admin

[melloware]

Here is the fix Junit did: https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae#diff-25d902c24283ab8cfbac54dfa101ad31

[melloware]

@JLLeitschuh I submitted a PR for this so we will see. I feel like its totally harmless since the method is deprecated anyway.

[JLLeitschuh]

After spending some time talking with some others in the security community, defaulting to having a CVE number assigned is prefered. It will help keep the ecosystem sane by providing one common identifier between all organizations (Sonatype, Snyk, ect...)

With respect to: https://github.com/google/guava/pull/5324

Can someone from Google make an official statement on whether or not this issue will receive a CVE number or not?

I'd prefer if Google did the CVE issuance for this vulnerability, but since I haven't gotten an official statement about it, I'll just go to the parent CNA, MITRE, to request it.

[melloware]

Once you get a CVE number please come back and edit this Ticket title to add the CVE number.

[JLLeitschuh]

Stating that I was going to file a formal appeal to MITRE finally got action on behalf of Google. They have assigned CVE-2020-8908 which should be disclosed later this week.

[tony--]

The last sentence in the CVE description says, "We recommend updating Guava to version 30.0 or later, or update to Java 7 or later, or to explicitly change the permissions after the creation of the directory if neither are possible."

The ", or update to Java 7 or later," clause suggests that this vulnerability only affects Java < 7, but that's not true, is it? That is, the problem is that Guava < 30.0 uses the old, vulnerable API from Java 6. Updating to Java 7 won't fix this, so that clause should be removed from the recommendation, shouldn't it?

@JLLeitschuh will you comment, please?

[JLLeitschuh]

@tony-- you are correct. Updating to Guava 30.0 won't fix this either. All that 30.0 changes is marking the method as deprecated. #5324 is a fix for it, but it's not been merged yet.

[tony--]

@JLLeitschuh thanks for responding. Any suggestion for how to communicate the need to update the CVE? I didn't realize it was SO WRONG.

[JLLeitschuh]

I've sent the following message to the Google security team.

Hi Google Team,

The CVE description states the following: https://nvd.nist.gov/vuln/detail/CVE-2020-8908

We recommend updating Guava to version 30.0 or later, or update to Java 7 or later, or to explicitly change the permissions after the creation of the directory if neither are possible.

Neither the first two of these actually fixes the issue. The Google Guava team haven't actually fixed the issue, they've just deprecated the vulnerable method. Updating to Java 7 also doesn't fix the vulnerability, unless you also change your method call.

This is clearly causing confusion for your users: https://github.com/google/guava/issues/4011#issuecomment-765672282

I just want to put this out there. This whole interaction with the Google security team as well as the Guava developers on this issue has been really unpleasant. Multiple times I've asked for follow up without any responses. I feel like I'm herding cats here. I'm bothered that you didn't run the CVE description by me before publishing it. This whole interaction has come across as very disorganized. Frankly, I'm unimpressed.

Combine that with the fact that this vulnerability was determined to not be bountyable, and I'm left with kinda a sour taste in my mouth over this whole thing. I feel like I'm doing a bunch of heavy lifting communicating with your users about this vulnerability, and the only bit of official communication by Google on this issue wasn't even factually correct.

This makes me hesitant to even try to report issues in your OSS via this channel in the future. If you'd be willing to offer some suggestions here, I'd appreciate it. Otherwise, I'm happy to just go the full-disclosure route via the GitHub issue tracker for future OSS security vulnerabilities I find in your software components.

[tony--]

Any reply that you can share @JLLeitschuh ?

[nick-someone]

Hi @JLLeitschuh!

Nick from the Guava team here. I sincerely apologize for my radio silence on the matter. I take full responsibility for not having been well engaged in this process. I believe my inaction was driven from a sense of avoiding stepping on the security team's toes, or inadvertently causing more consternation by doing the wrong thing (saying something I shouldn't have, not understanding the nature of how to respond to Sonatype vulnerability notices, etc.).

I understand now that my inaction was precisely the wrong thing to have done here. Had I at least coordinated with the security team sooner and more deeply, we could have gotten a better CVE description, and I would have been more likely to answer questions and engage in this bug more fully.

I want to thank you, sincerely, for your detailed reproduction case, and your support in this bug. You've done a great service to users of Guava by helping them resolve their issues, and I also want to thank you for finding similar information disclosure vulnerabilities in other places (see "Similar Vulnerabilities" in https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp).

Currently, I and the security team are in the process of drafting a new CVE description that more accurately describes the issue and remediation options, which we will also send to you for review before publishing.

Additionally, you may be happy to know that Google's security team is working on a comprehensive security response process for Google's open source projects (like Guava). Once we've got the details sorted out, they will be visible in this repository's /SECURITY and similar places. This security response process is designed, among other things, to enable open source team members to take a more active role in collaborating directly with security researchers and resolving issues that are raised, which should hopefully avoid this type of negative experience in the future.

We really hope that you continue to actively contribute these issues in the future. Again, I apologize sincerely for not having responded well to this helpful contribution, and I really do appreciate your contributions here and to other projects.

Thanks.

[JLLeitschuh]

Wow, this is more than I expected out of this. Thank you for the kind, respectful, and very human apology here. I really honestly do appreciate it.

Additionally, you may be happy to know that Google's security team is working on a comprehensive security response process for Google's open source projects (like Guava).

Please do consider utilizing GitHub Security advisories as a part of this process. I know they aren't perfect yet, but I continue, as a GitHub star, to utilize my contacts inside of GitHub to improve their shortcomings. Although they do still have shortcomings, I still do believe, personally, that they are the best way to do OSS security vulnerability disclosure with GitHub.

Please also considering having an email contact. The reality is, even though this requires monitoring more channels, you're more likely to get a better disclosure the more comfortable the researcher is with the method/manner of disclosure. Be that email, or GitHub.

Currently, I and the security team are in the process of drafting a new CVE description that more accurately describes the issue and remediation options, which we will also send to you for review before publishing.

Awesome. I'm not sure how the CVE update/change notification system operates, but please do try to make sure the downstream advisories generated from that CVE are accurately updated.

Even better, patching the vulnerability would be good, even though the method is deprecated.

In summary, your message is very much appreciated. I'm hopeful to see these future changes. I have no doubt that I'll probably end up having to interface through them, for some Google project, sometime in the near future 😆.

[JLLeitschuh]

Quick update to everyone following this. I added a "workaround" section to the header of this document. I realized that was missing. Sorry about that.

This vulnerability can be fixed by explicitly setting the java.io.tmpdir system property to a "safe" directory when starting the JVM.

[cpovirk]

Trying to tie together various internal and external discussions over these past months:

• The CVE update is https://github.com/google/cvelist/pull/1.
• We don't think that https://github.com/google/guava/pull/5324 is enough: It could fix the problem for our -jre releases but not our -android releases. And if anything, I would suspect that our method's behavior is more likely to cause end users trouble on Android (where other apps can see the files, IIUC [edit: I'm wrong: It's private to the app in modern versions.] than elsewhere (typically servers, where fewer potentially dangerous processes have access). (Plus, as a mundane thing, I'm sure that some tools would not cope well with the need to individually mark every future Android release as vulnerable: 33.0-android, 33.1-android, 33.1.1-android, 34.0-android, .... So the result might well be that they continue to report every Guava release as vulnerable as a precaution.) [edit: Given that users on Android are generally not vulnerable, I should emphasize that people use our "-android" release on the server, too. So it would still make sense to label all such releases as vulnerable.]
• It seems very likely that we need to remove createTempDir outright. It is @Beta, so everyone who is using it should be prepared for the possibility that it could disappear. (We've found this to not be the case at all in practice, but the point stands that we have some kind of abstract "right" to do it, and we exercise that right occasionally. And in fact we've reserved the right to remove even non-@Beta classes for security reasons.)
• One possible alternative is to rename it to something like createProbablyWorldReadableTempDir. However, even if that is something that the security community would consider acceptable, I'm not sure there's enough reason to keep the method around (especially when a rename still requires users to update their code): Guava currently promises compatibility only with Java 7+ (where the secure nio equivalent is available) or Android (where the secure getCacheDir is available). So if we're going to disrupt people with a rename, we might as well disrupt them to move them to the secure variants.
• Any move to a Java 7+ secure variant can in principle break people (J2ObjC users, anyone who relies on putting the directory in a world-readable location (for cross-process RPC?)). But if those are the worst problems we can think of, then we can feel reasonably comfortable going through with it.

@nick-someone , @cgdecker , anything I missed?

[JLLeitschuh]

And if anything, I would suspect that our method's behavior is more likely to cause end users trouble on Android (where other apps can see the files, IIUC) than elsewhere (typically servers, where fewer potentially dangerous processes have access).

Hold up now, 🤯 this actually puts a whole new spin on my research project if this is true. Android apps hostile towards each other is a way more compelling security perspective on this whole issue.

That being said, in all my previous research (ie. googling random terms), I have been completely unable to track down any kind of documentation regarding the behaviours of the java.io.tmpdir in the context of android applications. Some of the documentation I read seemed to indicate that each android app gets its own protected temporary directory. But that has not been confirmed anywhere I've been able to find. @cpovirk, could you do me a favor and ask the android team directly about this issue?

Also, if there is public documentation I can point to regarding this issue, that would also be greatly appreciated. 🙂

[cpovirk]

One thing for us to think more about: While I feel pretty safe autoreplacing Google's usage of this method on the server with nio (at least after some earlier testing), we should figure out how easily Android users can migrate to getCacheDir. Challenges:

• They need a reference to a Context instance.
• Some code might be shared across Android and server, in which case neither nio nor getCacheDir is universally available.
• They might still need to create a fresh directory, not just dump files into getCacheDir where they might collide with other temporary files created by the same app. This means that they need to pick a unique name for the directory. Our method had a loop to try 10,000 names, each incorporating the system time and a counter, until one is available. Perhaps we should offer a Files.createArbitrarilyNamedDirectory(File parent) method so that callers can migrate to createArbitrarilyNamedDirectory(context.getCacheDir())?
• Even with uniquely named directories, I would not 100% rule out the possibility of interference with other code that uses getCacheDir. Maybe there's an app somewhere with code that assumes that that code is the only code the writes to getCacheDir, and if some other code writes a directory there, it gets confused? I do see some hits when searching Google code for getCacheDir[(][)]\s*[.]list(Files)?[(] pcre:yes lang:java -f:javatests. Some (but not all) are filtering the results before operating on them.

[cpovirk]

Eek, I hope I did not just say something completely false :) I will see what I can dig up about java.io.tmpdir on Android.

[cpovirk]

The Android docs for System.getProperties() claim that java.io.tmpdir is set to /sdcard. Presumably that is a shared directory. I suppose it's conceivable that files there magically are restricted to the creating app, but that... would not be my first guess.

However, I came across a comment internally that suggested that the default changed between Ice Cream Sandwich and Jellybean. Now it's supposedly the current app's cache directory. I haven't done all the archaeology on that yet, but I see a commit that looks related in that it copes with changes to java.io.tmpdir over time.

Still, Ice Cream Sandwich devices are out there. And in fact we still run Guava's tests against Ice Cream Sandwich. I wanted to include actual numbers from Google's Distribution Dashboard (to whatever degree we think that's representative of the real world), but it no longer includes them, referring us to "Android Studio's Create New Project wizard" for the information. So let's go with https://9to5google.com/2020/04/10/google-kills-android-distribution-numbers-web/ or https://www.xda-developers.com/android-version-distribution-statistics-android-studio/ instead. Each gives 0.2% ICS almost a year ago. So maybe we don't need to lose too much sleep over Android at this point.

[edit: I subsequently heard that you can download some distribution numbers in JSON format. However, the numbers there are probably an exact match to the ones in the pages I linked above. Notably, I see Ice Cream Sandwich at .2%, and I see no Android 11 at all! It sounds like the numbers may need to be updated manually, and presumably they haven't been.]