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?
Best Answer
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):
ls
)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 ontestfile.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.