1

I'm trying to wrap my head around file permissions on a Samba share and the following puzzles me why both user1 and user2 can delete each others files even though they don't seem to have the permission to do so. This is what those files look like on the ubuntu machine running the samba server:

-rwxr--r-- 1 user1 private 0 okt 8 00:43 'test file user1.txt'* -rwxr--r-- 1 user2 private 0 okt 8 00:06 'test file user2.txt'*

In case it somehow matters, both user1 and user2 are members of private. Both users are accessing the share via their respective windows machines, first creating their respective file, then deleting each others files.

In the smb.conf this share is configured as follows:

 [Together] path = /srv/together browseable = yes read only = no writable = yes create mask = 0755 directory mask = 0755 valid users = @private force group = private

My best guess is that the valid users parameter is much more powerful that I thought, basically elevating all members of the group to the status of owner. Is this so?

Edit: (in response to the comments)

The parent directory has the following permissions:

drwxrwx--- 19 root private 44 okt 8 00:58 together/

So I guess that this is what warrants the deletions. I guess I need to do a crash course in linux file permissions. It would never have occurred to me that deletion is not simply a special kind of edit... So does this mean that if the users had tried to edit the files, they would not have been able even though deletion worked fine?

The hint at the sticky bit t is also helpful. Thanks.

As for extended ACL support: yes it is on (apparently by default) but I can't quite seem to grasp what that means for my "problem" (if we assume for a minute that the parent directory permissions didn't explain things). Would extended ACL have to be on or off to create the kind of behaviour I'm seeing?

Improve this question
5
  • 1
    Is extended ACL support enabled? Commented Oct 8, 2018 at 1:08
  • 8
    What are the permissions on the directory? When deleting files it is the permissions on the directory that matter. Commented Oct 8, 2018 at 1:56
  • 1
    In addition to what Zoredache said, do you have another share that includes together, e.g. on /srv? Because that could also interfere. Commented Oct 8, 2018 at 9:34
  • 1
    You can use the sticky bit t on the directory to limit the delete rights to the directory and/or file owner. Commented Oct 8, 2018 at 13:23
  • I edited the question in response to some of the comments. So how do we turn this into something useful for others? Perhaps someone could turn @Zoredache's comment into an answer (perhaps integrating the hints from the other comments as well, as they all seem valid possible explanations for what looked really mysterious to me)? Feel free to elaborate ;-) Commented Oct 8, 2018 at 20:07

1 Answer 1

Reset to default
5

Ok, I'll try to sum it up here and give you a quick explanation about how Linux permissions work (without including ACLs) and why they work like that:

First in short to give the answer: to delete a file from inside a directory you need write permissions on the directory and not on the file itself.

Explanation:

A directory is only a special kind of file which contains information about files and their inode numbers (inodes are basically the metadata of a file, e.g. where exactly on the hard drive the data content of the file is stored, permissions on the file etc.), in short it's basically a text file that contains a list of the files inside of it.

E.g. when you use ls you basically read the list from inside the "directory-file" (that is why you need read permissions on a directory to list its contents).

A file only exists (with some exceptions but this is too much for this post) as long as there is some "link"/"list entry" pointing to it, aka it is listed inside some directory. If you delete all listings of a file from every directory it is listed in, the file (and its data) is gone. This is a bit complicated to understand but for now let's just assume a file exists only once.

I hope this makes it clear why you need write permissions on the directory and not the file itself to delete it, because again, a directory is only a "text-file" that contains a list of its contents. If you erase the entry for a file from the "directory-file" it is listed in, you effectively delete the file.

So again, directories are only a special kind of file for which the permissions have slightly different meanings (well not really if you think about it, only for the execute permission):

  • read (r or 4) -> list the names of the directory contents (e.g. with ls)
  • write (w or 2) -> modify the "directory file", required to delete files inside that directory, also needed to create files inside that directory (if you think about a directory as a text file it makes it easier to understand this concept)
  • execute (x or 1) -> change into this directory and read the inodes of the files inside the directory (this is the biggest difference between a directory and a "normal" file). Without it you cannot access any file within this directory and you cannot cd into it, e.g. if you don't have x-permission on the directory /test you cannot access /test/testfile.txt, even if you have read permissions on testfile.txt. Basically the x-flag is the read permission for the inodes inside a directory.

If you're interested in more information on the topic of permissions check out this introduction into Unix file and directory permissions by Professor Pollock, it also goes briefly into ACLs (which is basically kinda how Windows does it, you set permissions for each folder/file per user/group on top of assigning one user and one group): https://wpollock.com/AUnix1/FilePermissions.htm

If you're in the learning process of the Linux permission system I would refrain from using ACLs for now unless you really need more specific permissions.

Oh and btw: write permissions on a file inside that directory give you the permission to modify (write into) that file. In your example, user2 could not write into 'test file user1.txt' even though he can delete it.

Edit: I also wanted to add an explanation about inodes and how they interact with directories etc. but decided this would go to far in this post. If you're interested there are a lot of great sources on the topic out there but it really shouldn't concern you too much if you just need to set up your Samba.

Improve this answer
4
  • 2
    Here is the most recently updated version of Professor Pollock's Unix File and Directory Permissions and Modes. Commented Oct 9, 2018 at 9:06
  • 1
    Great explanation! I realized though, that although my question was about Samba, the answer was not Samba specific at all. So I created another to address my lingering confusion about the relationship between Samba permissions and file-system permissions at superuser.com/questions/1365142 Commented Oct 9, 2018 at 10:43
  • 1
    @Christoph It's the same in Windows: If you just create a share, NTFS file permissions still apply. It's also wanted behavior. Without it security would be a real issue. Think of Samba as something that sits on top of your normal file permissions and its only job is to give you remote access. It's the same for any other service, (s)ftp, webservers, all are built on top of the normal file permissions. Commented Oct 9, 2018 at 16:48
  • @Broco Thanks for explaining. I understand that Samba is built on top of the normal file permission, but that does not necessarily imply that it is build in such a way that permissions need to be set in two places. My initial assumption was that Samba would automatically translate between the two levels of permission, but I now understand that this translation needs to be actively configured. I'm not complaining about it. I see the point. But it still poses a challenge as to how that translation works. (And I didn't mean to imply that your answer should have taken that up. It's fine.) Commented Oct 10, 2018 at 8:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.