3

I have these files:

-rw-rw-r-- 1 root   adm    0 Jun 22 11:25 a
-rw-rw-r-- 1 wilmes wilmes 0 Jun 22 11:23 b

When I cp b over to a as user wilmes why does it keep the original owner of a (root)?

I use this command (no aliases): cp b a

Why does it fail when I use -p in command cp -p b a ?

cp: preserving times for 'a': Operation not permitted

I noticed this on Ubuntu 17.04 with ext4. User wilmes is member of group adm and the containing directory looks like this:

drwxrwxr-x 2 wilmes wilmes 4,0K Jun 22 12:09 ../user/

And most important: Where is this documented?

martinw
  • 133
  • 3
    You may edit your question and add full paths and your fstab as a reference. This type of things use to happen when you're writing to a remote datastore such as a remote nfs one, for instance. – Marco Jun 22 '17 at 10:20
  • @Marco There is no remote datastore involved. Plain local ext4 file system in /var/tmp/ –  Jun 22 '17 at 12:39

2 Answers2

4

It fails because you need to be the target (a) file owner, cp will not override basic unix security. A user can preserve their own files, wilmes -> wilmes, but cannot do so for other users, and certainly not for root. I am assuming that you are not logged in as root, nor as wilmes.

In this case, one file is owned by root, the other owned by wilmes. To preserve, you should try running:

sudo cp -p b a

Relevant links:

Example:

Create a file for root, a, and a file for a standard user (joe), b.

joe@testbed:~/tmp2$ sudo touch a
joe@testbed:~/tmp2$ touch b

Verify that the permissions are correct.

joe@testbed:~/tmp2$ ls -l
total 0
-rw-r--r-- 1 root    root    0 Jun 22 13:51 a
-rw-r--r-- 1 joe     joe     0 Jun 22 13:51 b

Attempt to copy user owned file, b, over root owned file (which would violate permissions):

joe@testbed:~/tmp2$ cp -p b a
cp: cannot create regular file 'a': Permission denied

Repeat copy as root, permissions preserved:

joe@testbed:~/tmp2$ sudo cp -p b a
joe@testbed:~/tmp2$ ls -l
total 0
-rw-r--r-- 1 joe joe 0 Jun 22 13:51 a
-rw-r--r-- 1 joe joe 0 Jun 22 13:51 b

Note: Permission denied, not Operation not permitted. I imagine that you see not permitted because the user wilmes DOES have access to the file, by means of a group, however, they are not the owner, so they cannot entirely overwrite it.

Logically, you're replacing a file that belongs to another user (root) and asking the system to also make you the owner of that file, that would be a catastrophic security flaw.

For example, what if I came a long as a normal user, malicious.username01 and wanted to replace the crontab for something like ntp which belongs to root? If what you are trying to do worked, I could simply write my own malicious version of it and then simply cp -p my-malicious-script /etc/cron.daily/ntp. This would be terrible. Really really terrible.

  • Actually I do the copy as user wilmes. And that is what I don't uderstand: There is not trace of user wilmes modifying the file afterwards. –  Jun 22 '17 at 12:42
  • Did you try running it as root? –  Jun 22 '17 at 12:45
  • Sorry, I know that it works as root or by sudo but I try to understand why cp produces this exact result. From my point of view it would be more intuitive if the owner would change by default. –  Jun 22 '17 at 12:47
  • Joe is right. What uid are you logged with when doing such cp? Type id in your terminal and paste output. – Marco Jun 22 '17 at 13:00
2

When I cp b over to a as user wilmes why does it keep the original owner of a (root)?

Because cp by default (without -a or -p flags) doesn't modify the time or the owner of the target file. In your case, the file a is owned by root, but since you have write access through the group, you can modify the file, including truncating it and rewriting it completely. What you can't do, is to modify the timestamps, since only the owner of the file can do that.

If the target file didn't exist, it would be created with the uid of the user running cp, i.e. wilmes. (And without superuser privilege, you couldn't change the owner, either.)

However, since you have write access to the directory, too, you could remove the target file first, and then recreate it, in which case it would be owned by the user running cp.

ilkkachu
  • 138,973