Somewhere between v4.12 and v4.13 (all the way up to v4.15) vfs_streams_depot started to ignore "directory mask = 0777" and is creating the directories with 0755 permission which leads to the fact that nobody else can delete/modify the file if it has a stream attached ("create mask = 0777" still works and the stream can be modifyed but not the file). More then that, if the streams folder is outside the share path it generates this error: ... conn_rootdir =/samba/shareddata resolved_name=/samba/.streams/9A/8D/9FC36137C23292243000640000000000 smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_INVALID_PARAMETER] || at ../../source3/smbd/smb2_create.c:334 smbd_do_qfsinfo: level = 1007 check_reduced_name: Bad access attempt: . is a symlink outside the share path ...
We are trying to discourage access outside the share folder, for obvious reasons.
I checked back in the git history and vfs_streams_depot has *always* used 0755 when creating directories within the streams folder. Here is the initial commit creating vfs_streams_depot.c dfd05b9b65c5ad12dbb64b626d3180fb9e21ccb0 If you look inside you'll see: + if ((SMB_VFS_NEXT_MKDIR(handle, rootdir, 0755) != 0) + && (errno != EEXIST)) { + goto fail; + } + + tmp = talloc_asprintf(result, "%s/%2.2X", rootdir, first); + if (tmp == NULL) { + errno = ENOMEM; + goto fail; + } + + if ((SMB_VFS_NEXT_MKDIR(handle, tmp, 0755) != 0) + && (errno != EEXIST)) { + goto fail; + } + + TALLOC_FREE(tmp); + + tmp = talloc_asprintf(result, "%s/%2.2X/%2.2X", rootdir, first, + second); + if (tmp == NULL) { + errno = ENOMEM; + goto fail; + } + + if ((SMB_VFS_NEXT_MKDIR(handle, tmp, 0755) != 0) + && (errno != EEXIST)) { + goto fail; + } + + TALLOC_FREE(tmp); + + if ((SMB_VFS_NEXT_MKDIR(handle, result, 0755) != 0) + && (errno != EEXIST)) { + goto fail; + } When did this ever look at "directory mask =" ? I don't see any commits that would change that from inception onwards. Also, it's very unlikely we will allow stream folders outside of the share path, as it's very dangerous to allow this. It may have worked in the past, but increased awareness of security means this will almost certainly be disallowed in the future.
OK. The fact that it must reside in the share path is a little annoying (visually) but the access rights are making it unusable because if a group has read/write access over a file but user A (member of that group) adds a stream, than that file becomes read-only for everyone except user A (and root if root is a also a samba user) because smbd drops root privileges and suid to the acccessing user and that coroborated with the 0755 dir create mode (and file crete mode) leads to group haveing read-only access.
Did it ever work ? Seriously. Did you have a working implementation before ? If so, can you describe exactly what it did in terms of user access rights, and I'll take a look at fixing it.
Well... Previously of version 4.13 I kept the streams directory outside of the share path and with "directory mask" and "create mask" both set to 0777 it is usable. The access is done based on the parent file ACL so that only the users that have r/w on the main file have rw access on the streams. I have changed all SMB_VFS_NEXT_MKDIRAT in vfs_streams_depot.c from 0755 to 0777 and it works as before (if I move the streams directory from outside share path, inside it). I have saw that 0755 was set even in v4.12 but something has changed somewhere. I don't know what and where because the diff is very large and I don't know the insides of Samba.
Oh, I know why the "streams directory" outside of share path isn't working. Let me see what I can do here..
I actually think I have a simple fix for this, but I'll start work on it again on Monday.
Created attachment 16691 [details] git-am fix for master. Can you check this fix with 4.15.rc1 ? It should fix the problem of allowing streams directories outside of the share path. I've been thinking some more about this and it isn't a security issue, as this module is the only code that access that exterior path, there's no other way to get to it within normal code paths.
Unfortunately I can't test build v4.15 because I have to create a VM for that and for the moment I lack the time, but I did build it in v4.14.6 and it works.
Yeah, unfortunately the fix isn't quite right yet as I added some regression tests. I'm still working on it.
I've finally found time to fire up a test environment (Fedora35 rawhide in docker) and tested up v4.15.0rc2 with your patch. It works for may use-case (with create mode set up as 0777). The test server is an AD member.
Created attachment 16744 [details] git-am fix for master, 4.15.RCnext Put this into CI as: https://gitlab.com/samba-team/devel/samba/-/pipelines/354829037 I found the problem with the tests :-).
This bug was referenced in samba master: 161cee6f36b1642e2096a64a4eec22a1ebf82aa2 5fdf4219c6db6d81ebe608c4313c9c9aea6dbc7c 1e3232006d688fa999fb8314ce948ffb45a50e71 649f544ab2cf564cdecf545c549ca9703cb5cda4
Created attachment 16745 [details] git-am fix for 4.15.RCnext. Cherry-picked from master.
Note, the fix for https://bugzilla.samba.org/show_bug.cgi?id=14805 needs to go in before this bugfix to ensure the known failure added here is determinstic across all platforms.
Comment on attachment 16745 [details] git-am fix for 4.15.RCnext. lgtm
Reassigning to Jule for inclusion in 4.15 (note: see comment #15 from Jeremy, needs fix from bug #14805 first)
Pushed to autobuild-v4-15-test.
I have patched v4.14.6 (current stable from Fedora 34) with this patch and that for bug 14805 and released it into the wild (production). Apparently it works. But still I have a misunderstanding: if the directory mode is 0755 (and the file mode is 0644) how it is supposed to work in a multi-group environment where different users from different groups should modify same/different streams (assuming that that groups have full access on the main file)?
This bug was referenced in samba v4-15-test: 20ec0ea95e936ce4d1e9243cd377376fd5778575 6b5f770790ca8a1ef6ad89bc8db6e6f8a70fb58e 185f191bd43c9442e20b2e5f74171131f5e3fd57 12f76f4292a9e56c3b6d8f549378292dc87b1ecb
This bug was referenced in samba v4-15-stable (Release samba-4.15.0rc3): 20ec0ea95e936ce4d1e9243cd377376fd5778575 6b5f770790ca8a1ef6ad89bc8db6e6f8a70fb58e 185f191bd43c9442e20b2e5f74171131f5e3fd57 12f76f4292a9e56c3b6d8f549378292dc87b1ecb
(In reply to Dinu-Razvan Chis-Serban from comment #19) Reassigning to Jeremy to answer the comment #19.
I'm going to close this out. The permissions problem is a different issue. To be honest no one has worked on the permission issue. The existing code hasn't changed in that respect since creation, so one could argue it's "working as designed". Now whether that design is correct, and should be fixed is another matter (and a different bugid :-).