install: create destination file with safer modes before copy

[nerdroychan]

Fix #6435.

As is suggested by the original issue, the creation of the destination file is delegated to fs::copy which creates the file with default mode 0644. This makes the file readable by other users before the final chmod is done, which is potentially unsafe and inconsistent with GNU install.

Since the current implementation unconditionally removes the destination path before the copy, creating the file with a minimal u=rw permission would not hurt the copy. This patch implements this (for unix).

[sylvestre]

Could you please add a test to make sure we don't regress? Thanks

[nerdroychan]

Could you please add a test to make sure we don't regress? Thanks

There was indeed a regression: when the fs::copy call failed, the created destination file was not removed. I just pushed a new patch that fixes this.

I added a test to make sure that no file will be created when fs::copy fails (e.g., the source file cannot be read), and if it succeed, the destination file's mode is set correctly. This makes sure that it works as before no matter the copy succeeds or not.

I'm not sure how to use a test case to check whether the new file is created in mode 0600, since the creation is in the middle of an internal function, but the strace output confirms so If you have any suggestions please let me know. Thanks!

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/inotify-dir-recreate (fails in this run but passes in the 'main' branch)

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/rm/rm1 (passes in this run but fails in the 'main' branch)

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/timeout/timeout. tests/timeout/timeout is passing on 'main'. Maybe you have to rebase?
Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)