37

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.

Improve this question
1

2 Answers 2

Reset to default
64

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.

Improve this answer
0
12

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.

Improve this answer
6
  • 3
    Commonly known as hard links.
    – Bob
    Nov 3, 2014 at 0:32
  • 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
    Nov 3, 2014 at 18:41
  • 3
    There 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
    Nov 3, 2014 at 19:44
  • @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
    Nov 3, 2014 at 20:12
  • 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
    Nov 4, 2014 at 5:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .