Bug 11431

Summary: cp ignores read-only permission on existing destination file overwrite conditions
Product: Busybox Reporter: Daniel Kirkdorffer <dankirkd>
Component: Standard ComplianceAssignee: unassigned
Status: NEW ---    
Severity: major CC: busybox-cvs
Priority: P5    
Version: 1.28.x   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Host: Target:
Build:

Description Daniel Kirkdorffer 2018-10-24 22:19:39 UTC 
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.
Comment 1 Daniel Kirkdorffer 2018-10-24 22:20:30 UTC 
Note: specifically using busybox 1.28.4-r1
Comment 2 Daniel Kirkdorffer 2018-10-24 22:29:36 UTC 
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
Comment 3 eureka 2018-10-24 23:06:31 UTC 
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
Comment 4 Daniel Kirkdorffer 2018-10-31 19:22:20 UTC 
Are there any other opinions on this issue?