smb2.session.reauth4: UID/GID to use as anonymous user when modifying DACL

[Xavi Hernandez]

Hi Stefan,

On Mon, Jun 17, 2024 at 12:30 PM Stefan Metzmacher <metze at samba.org> wrote:

> Hi Xavi,
>
> >>> At the same time, I can also see that getuid()/getgid() returns 0/0 and
> >>> geteuid()/getegid() also returns 0/0. Does the default plugin use
> >>> uid/gid 0/0 while performing this operation?
> >>>
> >>> I have the following questions
> >>> 1) What are we testing for with this smbtorture test?
> >>> 2) Is the anonymous user allowed to modify the DACL of the file as done
> >>> in the test? This would obviously lead to access denied errors as we
> >>> see currently.
> >>
> >> It checks the reauthentication has no effect on open file handles
> >> only on new file handles. After the SMB2 Create only fsp->access_mask
> >> matters for access checking.
> >>
> >>> 3) What uid/gid should be set when performing this action as the
> >>> anonymous user?
> >>
> >> Maybe you need to remember the low level token at open time
> >> and use that.
> >>
> >
> > I'm not sure if this will work in all cases. When the acl_xattr vfs
> module
> > is used, the Windows ACLs are stored in "security.NTACL". To correctly
> set
> > this xattr, the process needs to become root on a kernel mounted
> filesystem
> > because the kernel doesn't allow a regular user to modify that xattr,
> even
> > if the user has permissions to modify the file.
> >
> > If a share uses a vfs module instead of a kernel mount to export the
> > filesystem, and that filesystem also requires root privileges to modify
> the
> > "security" namespace, then using the cached permissions at the time of
> > opening the file won't be enough.
> >
> > I think that the unix token should be kept consistent with the effective
> > owner of the process at all times to avoid this problem or similar ones.
>
> We have get_current_utok(), which refects become_root().
> Currently that can be used instead of
> handle->conn->session_info->unix_token.
>

That's exactly what I was looking for. Thanks !

Just to try to understand it a bit better, what's the reason that the
"conn->session_info->unix_token" is not kept in sync with the effective
process owner instead of keeping another unix token which is in sync ?

Is it just because become_root() doesn't receive a "conn" argument, or
there's some other reason ?

Xavi