How come one user can delete another user's 755 files?

I have a backup upload script that scp’s files to another server using the user upload. Another script on the target server then chown’s these to another user and sets the file mode to 755.

If I then SSH into the target server using the upload user, I’m able to delete the chowned files. Shouldnt they be read only?

Here is what a file looks like on the target server, and the user upload is able to delete it.

-rwxr-xr-x 1 maciekish maciekish 650M Nov  1 01:07 2014-11-01-data.tar.bz2

The user upload was just added using useradd and is not a part of the maciekish group.

When trying to delete the file as upload via ssh I get the question whether I want to delete “write protected regular file” and I’m able to say Y and delete it.

Maciej Swic

Posted 2014-11-02T13:07:46.627

Reputation: 730

Essentially a duplicate of Why can rm remove read-only files?

– G-Man Says 'Reinstate Monica' – 2014-11-03T17:29:56.417

Answers

The files are read-only; however, deleting a file doesn't modify it but only the parent directory (it basically removes the file from directory listing) – and it sounds like you have full write permissions to the directory.

You can set the sticky bit—aka “restricted deletion” flag—which will prevent anyone except the owner from renaming or deleting files in that directory (like in /tmp). To do this, run chmod o+t *directory* as the owner of the directory.

user1686

Posted 2014-11-02T13:07:46.627

Reputation: 283 655

In a typical Unix filesystem, any file can be identified by an arbitrary number of directory entries, each of which holds a "hard link".

From an implementation standpoint there is a difference between deleting the last directory entry (hard link) for a file and simply deleting one reference out of of many. However, from a semantic standpoint there is no difference.

If multiple hard links exist to a file, writing to the file using any of them alters the file seen by all of them. Using rm on a link, however, merely causes the file to not be accessible via that link. Other links to the file continue to see the exact same file.

supercat

Posted 2014-11-02T13:07:46.627

Reputation: 1 649

3Commonly known as hard links. – Bob – 2014-11-03T00:32:47.707

1@Bob: I know the term "hard link" is used to describe references that are created to an already-existing file; in cases where a file has never had more than one reference to it, is that lone reference still called a "hard link"? – supercat – 2014-11-03T18:41:06.287

3There is no difference between the links. Create file A, create hard link B, delete file A. Is B now a file or a hard link? For understanding how it works, it's better to see it as N hard links and not as 1 file and (N-1) hard links. There's also the links that exist when a file is opened. – gnasher729 – 2014-11-03T19:44:36.383

@gnasher729: I agree that in cases where multiple links exist or have existed to a file, it makes sense to refer to all of them as "hard links" if there's no semantic difference between them. On the other hand, I would think that from both a semantic and performance standpoint there could be advantages to distinguishing between a directory entry that has always been the only reference to a file, versus one to which other hard links may have been created. In any case, I didn't know whether it would be correct to refer say of the directory entries, "each of which is called a 'hard link'". – supercat – 2014-11-03T20:12:57.417

2@supercat it's not incredibly common, but it is correct. Consider the st_nlink ("number of hard links") field in struct stat. Put simply, directories hold hard links to files. – hobbs – 2014-11-04T05:45:21.280

@hobbs: Do you like my edit? – supercat – 2014-11-04T17:54:00.630