Fix modular jar final permissions

[laurentgo]

When a new modular jar file is generated with maven-jar-plugin with Java 11, the final permissions of the file are restricted to the current user instead of using the environment umask which usually allows for group and other users to access the file as well.

This is caused by the use of Files#createTempFile() which has a restrictive file permission model for security reason but as the temporary file is generated next to the original jar file, and there's no sensitive reason to restrict its access, the restrictive file permission should not be needed.

Fix the issue by creating a simple temporary file generator method.

Fixes #332

[plamentotev]

Hi,

Thanks for the contribution. createTempFile accepts array of FileAttribute. I wonder if we can use it to create temp file with the same permissions as the original file.

[plamentotev]

Also I noticed that the temp file is not marked for deletion. So if the move operation fails the temp file will be left on the filesystem.

[laurentgo]

Thanks for the contribution. createTempFile accepts array of FileAttribute. I wonder if we can use it to create temp file with the same permissions as the original file.

Yes, it is possible but as the other tools uses the default umask, I thought this was not needed. Do you want me to implement this behavior though?

Also I noticed that the temp file is not marked for deletion. So if the move operation fails the temp file will be left on the filesystem.

As far as I can tell from the javadoc, Files.createTempFile(...) does not mark the file for deletion either, so it is also an issue with the existing code. Do we want to address it in this change as well?

[plamentotev]

Thanks for the contribution. createTempFile accepts array of FileAttribute. I wonder if we can use it to create temp file with the same permissions as the original file.

Yes, it is possible but as the other tools uses the default umask, I thought this was not needed. Do you want me to implement this behavior though?

I'm not sure I follow which tools you have in mind. In this case it seems more robust to use explicitly the same permissions as the original file as this is the intended behavior if my understanding is correct.

Also I noticed that the temp file is not marked for deletion. So if the move operation fails the temp file will be left on the filesystem.

As far as I can tell from the javadoc, Files.createTempFile(...) does not mark the file for deletion either, so it is also an issue with the existing code. Do we want to address it in this change as well?

Yes, this is the existing behavior. If you want and think it makes sense would be great if you can add this change as well.

[laurentgo]

Thanks for the contribution. createTempFile accepts array of FileAttribute. I wonder if we can use it to create temp file with the same permissions as the original file.

Yes, it is possible but as the other tools uses the default umask, I thought this was not needed. Do you want me to implement this behavior though?

I'm not sure I follow which tools you have in mind. In this case it seems more robust to use explicitly the same permissions as the original file as this is the intended behavior if my understanding is correct.

I was referring to jar tool or java (when using Files#createNewFile()

[laurentgo]

Also I noticed that the temp file is not marked for deletion. So if the move operation fails the temp file will be left on the filesystem.

As far as I can tell from the javadoc, Files.createTempFile(...) does not mark the file for deletion either, so it is also an issue with the existing code. Do we want to address it in this change as well?

Yes, this is the existing behavior. If you want and think it makes sense would be great if you can add this change as well.

I can add the change. Most likely would not rely on DELETE_ON_CLOSE as the file is being moved, but will add a catch or finally block instead.