Thank you very much!

@davidebeatrici Just relialized that besides temp files, there are many other places OneDev creating files on host to be accessed by container processes, such as cache files, git clones, unzipped files as result of dependendy resolving , etc. Changing all of these to allow group access explicitly will be very cubersome and even not possible (git clones etc). I think reverting this change and relying on umask instead is a better approach.

Those are actually not an issue, because the default permissions under normal circumstances are 755 (folders) and 644 (files).

It's Java's java.nio.file.Files.createTempDirectory() and java.nio.file.Files.createTempFile() that enforce 700 (folders) and 600 (files), overriding anything that is applied on the parent directory (including umask).

With my patch applied we explicitly set 770 (folders) and 660 (files), allowing a group such as 100000 (Docker's remapped/namespaced root) to read/write temporary files and directories. This doesn't lower security by any means because without the setfacl commands (as in my example), the group is going to be the same as the user (whatever the service/application is running as).

Thanks. I was testing the original temp file creation which uses the non-nio version and respects umask. The original temp directory creation does use nio version and created as 700.

You're welcome. I wasn't aware they changed the default behavior with the new API, but it makes sense because when shared paths such as /tmp are used permissions should be as restrictive as possible.

And the old API doesn't support setting permissions, which is why I switched to NIO for files as well.

OneDev overwrites temp directory to be under its installation directory, so never writes to /tmp. But changing permission bits still required for temp directory creation. Also modified the code to only use permission bits on systems supporting posix, otherwise OneDev crashes on Windows.

Thank you. I expected the POSIX functions to be a no-op on other platforms, but evidently that's not the case...

I just tested release 3.2.1 with the packaged onedev-agent on OpenMandriva and it works.