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?

5
  • 1
    Is extended ACL support enabled? – Harry Johnston Oct 8 '18 at 1:08
  • 8
    What are the permissions on the directory? When deleting files it is the permissions on the directory that matter. – Zoredache Oct 8 '18 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. – Broco Oct 8 '18 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. – Thomas Oct 8 '18 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 ;-) – Christoph Oct 8 '18 at 20:07
3

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.

4
  • 2
  • 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 – Christoph Oct 9 '18 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. – Broco Oct 9 '18 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.) – Christoph Oct 10 '18 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.