Why can users delete files on Samba share when they apparently don't have permission to do so?

Question

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?

Answer 1

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.