[llvm] [lit] Ignore src permissions when copying lit_test_times (PR #121377)

[Angus Lees via llvm-commits]

anguslees wrote:

Apologies, I would have included a much longer explanation if I'd realised this change was controversial!

> As it's generated by lit, I wouldn't expect it to ever have read-only permissions. That would suggest that the problem is either in the creation of the sandbox (perhaps a file has been included in the sandbox image or whatever is used to initialise things that shouldn't have been), or possibly in the test stuff itself.

Bazel runs each 'action' (usually a single command) in a new sandbox, so it can cache/parallelise at the level of individual commands.  Bazel is a bit loose with file permissions, and generally only tracks "executable" or "not executable".  Different sandbox implementations provide the 'input' files to each action in different ways - eg a hardlink/symlink to a cached files, or an on-demand FUSE filesystem - and some of these protect the input files with read-only file permissions.

We can discuss whether that is "correct" or not, but I don't really have any authority or useful history to provide on this aspect of bazel.  🤷

> Which version of cp is this? The posix standard discusses a -p option to preserve permissions, which would imply that without that option, it shouldn't be preserving the permissions... NB: I haven't actually checked any real cp implementations to see what happens in practice.

In my real build environment (where I encountered this issue), I'm using busybox 'cp'.  Testing on a mac (using mac's cp) and Linux (coreutils 8.32), I get similar results:

```console
$ cp --version | head -n1
cp (GNU coreutils) 8.32
$ umask 002
$ touch foo
$ ls -l foo
-rw-rw-r-- 1 coder coder 0 Jan 12 22:04 foo
$ chmod a-w foo
$ cp foo bar
$ ls -l foo bar
-r--r--r-- 1 coder coder 0 Jan 12 22:04 bar
-r--r--r-- 1 coder coder 0 Jan 12 22:04 foo
```

I'm sure I can track down the relevant lines of code in coreutils, if you wish.  It's possible that this code is so old that I won't be able to track it back to a commit justification/explanation however.

Is there an actual concern that I need to respond to here?

https://github.com/llvm/llvm-project/pull/121377