The following demonstrates the expected behavior of "cp" when we try to copy a file over an existing read-only file: $ mkdir aaa $ cd aaa $ touch a.txt $ touch b.txt $ ls -laF total 0 drwxr-xr-x 4 user1 group1 136 Oct 24 12:25 ./ drwxr-xr-x 13 user1 group1 442 Oct 24 12:24 ../ -rw-r--r-- 1 user1 group1 2 Oct 24 12:25 a.txt -rw-r--r-- 1 user1 group1 1 Oct 24 12:25 b.txt $ chmod 440 *.txt $ ls -laF total 0 drwxr-xr-x 4 user1 group1 136 Oct 24 12:25 ./ drwxr-xr-x 13 user1 group1 442 Oct 24 12:24 ../ -r--r----- 1 user1 group1 2 Oct 24 12:25 a.txt -r--r----- 1 user1 group1 1 Oct 24 12:25 b.txt $ cp a.txt b.txt cp: b.txt: Permission denied However, when using Busybox "cp" (on Alpine 3.8), the operation succeeds without permission issues.
Note: specifically using busybox 1.28.4-r1
Further details on my environment: Running within a Docker container built with 0.27.2 of the docker-maven-plugin. $ uname -a Linux 1375916cea83 4.9.60-linuxkit-aufs #1 SMP Mon Nov 6 16:00:12 UTC 2017 x86_64 Linux
you're describing a non-standard behavior of cp (no-clobber flag in coreutils). simply setting a file to 0440 is not sufficient to stop cp from overwriting it (try cp -f on coreutils, it will succeed). cp calls unlink(2) which takes directory permissions into account, not the permissions of the link
Are there any other opinions on this issue?