On Thu, 14 Nov 2024 at 01:42, Ralph Boehme <slow@xxxxxxxxx> wrote:
> ok, I got a bit farther. It seems the client needs the mount option
> modefromsid to use this. Why? It's not even documented in the manpage.
> For a posix mount the behaviour to send a chmod(mode) as
> SMB2-SETINFO(SD, S-1-5-88-3-mode) must be the default.
>
> And then there's another problem. This commit from Ronny
>
> 0c6f4ebf8835d01866eb686d47578cde80097981
> cifs: modefromsids must add an ACE for authenticated users
>
> breaks this against Samba as Samba requires that this special SD has
> only a single ACE with the magic SID S-1-5-88-3-mode in
> check_smb2_posix_chmod_ace():
>
> if (psd->dacl->num_aces != 1) {
> return false;
> }
>
> I'm not sure I fully understand the reasoning in the commit messages,
> but I think a userspace chmod() should be mapped to an ACL with the
> single magic ACE and nothing else. Server should treat these SDs special
> int the way, that they will *only* apply the mode from the SID, the must
> not apply this as an SD (ACL) in the filesystem and hence to make this
> clear we assert psd->dacl->num_aces == 1.
>
> Am I missing anything? Thoughts?
I think I recall this was because the old behavior in modefromsids
completely broke
Windows and Azure servers (or in hindsight it probably broke EVERY
SINGLE non-samba server)
due to it while setting the magic -88-3 ACE but removing all other ACEs.
So, you can set the mode and never access the file again, ever, well
not until you go to the windows
server and repair the ACL.
I recall one reasoning for this flag, as well as its sibling idsfromsid,
is also for situations where you do NOT have multiuser mounts
but you want to make it still look like you can set uid/gid and mode
from linux clientside.
These options are not well defined and could benefit from better documentation
and possibly restrictions when they can be used and when they can not.
For the commit in question I think I recall we had to do it this way because
"we want these options to work against normal windows and azure shares"
and the old behavior was an easy to use "dos attack on share data".
