-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Files#createTempDir stopped working on Windows with 32.0.0 #6535
Comments
Sorry about that. I was aware that some version of Windows had gotten some kind of POSIX support but probably also had heard enough during our jimfs work that I should have realized that that didn't solve this. A teammate ended thinking to test Windows after the release, at which point he confirmed that it didn't work. But all we've done so far is update the release notes, add a warning to the Javadoc at head, and try to read some about how to create the directory securely under Windows:
In response to a similar problem, the JUnit people took the position that After some more searching around, I've come across https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/, which at least suggests that Windows is different than Unix. It says that Windows provides each app with its own temporary directory and so you don't have to worry about permissions there. But that source would be more reassuring if it didn't suggest that you can change the permissions of an existing directory and then rely on it to be secure... and probably also if it didn't assume that all non-POSIX systems have secure temporary directories. I found some more information that I haven't confirmed on Stack Overflow. (And I found that the Javadoc for I see from the Calcite issue you linked (thanks!) that this comes from a file in embedded-redis, a project that hasn't had a commit in over 4 years. So I assume it's not going to get fixed there. I also see that you have a workaround. I'd be interested to hear:
|
See JENKINS-71375. There are about 21,984 installations (across all operating systems) of the Jenkins Artifactory plugin, which is subject to jfrog/build-info#737 on Windows. As a result, Jenkins Artifactory plugin users who are running Jenkins on Windows are impacted by this issue. |
Thanks, and sorry: That's pretty impressively bad. I'll see what I can do about this tomorrow. If anyone else ends up here and has any implementation tips, let me know. I'm tentatively planning to try to set ACL permissions on the directory, even though it's probably already in a secure directory, just to be safe. (By the time I'm convinced that I can prove that the code is running on NTFS or similar, I'm hoping it's not much harder to set the permissions, too.) |
I think we should only be setting POSIX attributes when FileSystem#supportedFileAttributeViews contains
(This blog post goes into the gory details regarding why both My Windows 10 system had So it appears that the common case is for the directory returned by
OpenJDK itself does not attempt to deal with these corner cases. If this approach is good enough for OpenJDK, it might be good enough for Guava as well. If not, it might be best to simply fail fast with e.g. |
Thanks, that's all reassuring! I think I have figured out how to create the file with the desired ACL in the first place (by implementing |
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538491548
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 Relates to: - #4011 - #2575 - #2686. (It sure would be convenient to have Windows CI set up!) RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538492945
OK, I have pushed #6540 (but you should ignore the PR with the number just before that one...) with my attempt at a fix. If any Windows users are in a position to easily test whether it solves the problems of 32.0.0, please give it a shot. Otherwise, I will probably release 32.0.1 with that change and wait to hear comments after release :) |
Thank you! Yes, when I printed out all the permissions that a file had by default, I missed a newline before the first one, so I had (I'll also go back and add a test that we can create a file in the temporary directory, though that won't help much until we implement #2686.) |
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 Relates to: - #4011 - #2575 - #2686. (It sure would be convenient to have Windows CI set up!) RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538492945
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 Relates to: - #4011 - #2575 - #2686. (It sure would be convenient to have Windows CI set up!) RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538492945
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 Relates to: - #4011 - #2575 - #2686 (Yay, we have Windows CI set up!) - #2130 RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538492945
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 Relates to: - #4011 - #2575 - #2686 (Yay, we have Windows CI set up!) - #2130 RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538492945
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 Relates to: - #4011 - #2575 - #2686 (Yay, we have Windows CI set up!) - #2130 RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538492945
Based on [some discussions in GitHub](#6535 (comment)), I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to `java.nio.file.Files.createTempDirectory`/`createTempFile` passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is _not_ a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer. Fixes #6535 Relates to: - #4011 - #2575 - #2686 (Yay, we have Windows CI set up!) - #2130 RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under Windows. PiperOrigin-RevId: 538492945
I've released the fix: https://github.com/google/guava/releases/tag/v32.0.1 |
It bundles Guava 32.0.0 which has a bug on Windows where temporary directories can't be created, causing tests to fail. See google/truth#1137 and google/guava#6535
It bundles Guava 32.0.0 which has a bug on Windows where temporary directories can't be created, causing tests to fail. See google/truth#1137 and google/guava#6535
I wrote this documentation, and wrote the query, and I'm just going based upon what I heard from someone else. I've never actually confirmed this myself. I don't ever develop code on/for windows |
Small world :) Thanks. |
still reproduced for me on Windows with
|
Thanks, can you point the failure stack trace? I'm wondering if you're seeing #6634 (which I have a pending fix for) or some other issue. |
Unfortunately, the code is a bit more complex: there is a static {
if (SystemUtils.IS_OS_WINDOWS && System.getProperty("hadoop.home.dir") == null) {
winutilsDir = Files.createTempDir();
createWinUtilsFile();
}
} and this class can't be loaded when first time referenced at runtime with the error:
I tried to reproduce with the bare code (see https://github.com/radistao/guava-createTempDir), where only 'ConfigurationFactory' with static block exists, but not reproducible. The only thing i can confirm: in our jar (we use fat jar with bundled spring boot application) only guava has different version, the rest of the code an dependencies remained the same: If i have access to Windows development environment soon - i'll try to reproduce in debug mode. |
today i tried to debug in Intellij IDEA and it works successfully (team directory is created), but when i build to a fat jar and run as a spring boot application, i observe the following errors:
again: this happens when first time initializing class Yes, we use Windows Active Directory configuration, but currently i'm logged as non-domain user with admin privileges, and i run the application on behalf of the same user. Maybe also worth to mention: we run the application using Windows Service Wrapper for .NET4 (https://github.com/winsw/winsw), and the application registered and executed as a Windows Service. Hope this will shed some light on the issue. |
Thanks, that does sound likely to be the same problem as #6634. I have a fix out for review. |
ah, i missed that #6634 also refers to Windows Services. so yes, seems similar (at least now i was able to collect the logs to prove it) |
After update to guava 32.0.0
on Windows we start having such exception
seems it is related to
feb83a1
The text was updated successfully, but these errors were encountered: