Bug 15065 - Folder & file access permissions given to owner are derived from group setting
Summary: Folder & file access permissions given to owner are derived from group setting
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.16.1
Hardware: x86 Linux
: P5 normal with 2 votes (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-13 03:50 UTC by burgess
Modified: 2022-05-13 19:41 UTC (History)
0 users

See Also:


Attachments
log.smbd, level 10, for mounting share (at 10:25:02) and attempting open of 700 file (at 10:25:15) (336.73 KB, text/plain)
2022-05-13 17:48 UTC, burgess
no flags Details
log.smbd, level 10, for mounting share (at 12:24:05) and opening of 750 file (at 12:24:12) (4.38 MB, text/plain)
2022-05-13 19:41 UTC, burgess
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description burgess 2022-05-13 03:50:26 UTC
A shared folder or file is provided to its owner with group permissions, not owner permissions.

This is especially problematic for a top-level share directory that has permissions 700.  A share whose associated directory has those permissions cannot be mounted at all, even by its owner.

Repeat by:

1.  Find or create a file/folder on the server, somewhere within a share, with permissions 700 (rwx------).
2.  Attempt to open the file/folder via the share client.  Failure.
3.  Back on the server, adjust permissions of the file/folder to 750 (rwxr-x---).
4.  Attempt to view the file/folder via the share client.  Success.
5.  Verify Samba login username by placing a file on the share, then checking at the server to see if the username assigned to the new file matches the owner of the problematic file.

Verified for user "fred" using the following smb.conf (stripped-down vanilla skeleton version)

[global]
	workgroup = SAMBA
	security = user

	passdb backend = tdbsam

	printing = cups
	printcap name = cups
	load printers = yes
	cups options = raw

[fred]
	comment = Fred's Directory
	path = /home/fred
	valid users = fred
	browseable = Yes
	read only = No

Environment:  Server is Mac Mini with clean install of Fedora 36 and Samba 4.16.1.  Client is Mac Pro running MacOS "Mojave" 10.14.6.  Previous installation of older Samba on Fedora 35 worked fine in this same environment, so possibly something new in 4.16.1?
Comment 1 Jeremy Allison 2022-05-13 17:11:38 UTC
Can you provide a debug level 10 log of the access failure please ? That will help track this down. Of interest will be the process token used by the smbd whilst trying to get access to the 0700 directory.
Comment 2 burgess 2022-05-13 17:48:06 UTC
Created attachment 17288 [details]
log.smbd, level 10, for mounting share (at 10:25:02) and attempting open of 700 file (at 10:25:15)

This level 10 portion of log.smbd (4.16.1) shows:

At 10:25:02 AM, user "burgess" (UID 1000) mounts share "pub"
At 10:25:15 AM, user "burgess" attempts to open "foo.txt"

Server-side listing of "pub:
drwxrwxrwx.   2 root root     4096 May 13 10:20 pub

Server-side listing of "foo.txt", a file located directly under "pub":
-rwx------. 1 burgess burgess 32 May 13 10:20 foo.txt

The response from MacOS "Mojave" 10.14.6 was "The document "foo.txt" could not be opened.  You don't have permission."

I hope this gives some clues!
Comment 3 burgess 2022-05-13 19:41:27 UTC
Created attachment 17289 [details]
log.smbd, level 10, for mounting share (at 12:24:05) and opening of 750 file (at 12:24:12)

This level 10 portion of log.smbd (4.16.1) shows:

At 12:24:05 PM, user "burgess" (UID 1000) mounts share "pub"
At 12:24:12 PM, user "burgess" successfully opens file "bar.txt"

Server-side listing of "pub":
drwxrwxrwx.   2 root root     4096 May 13 10:20 pub

Server-side listing of "bar.txt", a file located directly under "pub":
-rwxr-x---. 1 burgess burgess 32 May 13 12:21 bar.txt

Upon double-clicking the file, MacOS "Mojave" 10.14.6 successfully opened the file and displayed the contents.

The only changes between the previous log and this one are the different filename (bar.txt instead of foo.txt, to avoid any caching issues) and the fact that bar.txt was set with server-side protections of 750 instead of 700.