On Tue, 11 Jun 2024 09:08:54 -0700
Jeremy Allison via samba <samba at lists.samba.org> wrote:
> On Tue, Jun 11, 2024 at 05:04:11PM +0100, Rowland Penny wrote:
> >On Tue, 11 Jun 2024 15:52:45 +0100
> >Luis Peromarta via samba <samba at lists.samba.org> wrote:
> >
> >> Again, my exact same experience.
> >>
> >> LP
> >> On Jun 11, 2024 at 14:58 +0100, Bailey Allison via samba
> >> <samba at lists.samba.org>, wrote:
> >> > Hey Rowland,
> >> >
> >> > Just wanted to say you are 100% correct, and it does
(seemingly)
> >> > nothing, at least within the context of setting Windows ACLs.
I
> >> > believe I have made a post on here a while ago with the same
> >> > observation, I will see if I can find it.
> >> >
> >> > For configuring of Windows ACLs, the only thing it initially
> >> > cares about is the owner user or owner group on the directory
> >> > you are sharing out. If you are either the user, or a member
of
> >> > the group you can then modify the ACLs, if you are not then
you
> >> > can't modify the ACLs.
> >> >
> >> > Regards,
> >> >
> >> >
> >
> >OK, there seems to be consensus on this,
'SeDiskOperatorPrivilege' no
> >longer seems to do anything.
> >
> >So, Jeremy do you know how it is/was supposed to work ? I would ask
> >the guy who appears to have added it, but Elvis has left the
> >building ;-)
>
> "git grep SeDiskOperatorPrivilege" gives:
>
> docs-xml/smbdotconf/misc/addsharecommand.xml:
> <literal>SeDiskOperatorPrivilege</literal>.
> docs-xml/smbdotconf/misc/changesharecommand.xml:
> <literal>SeDiskOperatorPrivilege</literal>.
> docs-xml/smbdotconf/misc/deletesharecommand.xml:
> <literal>SeDiskOperatorPrivilege</literal>.
>
>
> libgpo/admx/en-US/samba.adml: In order to successfully execute the
> add share command, smbd requires that the administrator connects
> using a root account (i.e. uid == 0) or has the
> SeDiskOperatorPrivilege. Scripts defined in the add share command
> parameter are executed as root. libgpo/admx/en-US/samba.adml: In
> order to successfully execute the change share command, smbd requires
> that the administrator connects using a root account (i.e. uid == 0)
> or has the SeDiskOperatorPrivilege. Scripts defined in the change
> share command parameter are executed as root.
> libgpo/admx/en-US/samba.adml: In order to successfully execute the
> delete share command, smbd requires that the administrator connects
> using a root account (i.e. uid == 0) or has the
> SeDiskOperatorPrivilege. Scripts defined in the delete share command
> parameter are executed as root.
>
>
> Looks like it is still checked (in master) in:
>
> _srvsvc_NetShareSetInfo()
>
> is_disk_op = security_token_has_privilege(
> session_info->security_token,
> SEC_PRIV_DISK_OPERATOR);
>
> /* fail out now if you are not root and not a disk op */
>
> if (session_info->unix_token->uid != sec_initial_uid()
&&
> !is_disk_op) { DEBUG(2,("_srvsvc_NetShareSetInfo: uid %u doesn't
have
> the " "SeDiskOperatorPrivilege privilege needed to modify "
> "share %s\n",
> (unsigned int)session_info->unix_token->uid,
> share_name ));
> return WERR_ACCESS_DENIED;
> }
>
> So it looks like it's still checked if you're trying to modify
> share definitions via RPC (at least in the old S3 rpc server).
>
> Jeremy.
>
I am not saying it isn't there, I am saying (and others have found the
same) that if you are setting share permissions from Windows, then
'SeDiskOperatorPrivilege' doesn't seem to do anything, what does
count
is that the user doing the change has ownership of the share or is a
member of the shares group, either must have full control. To put it
another way, you can set permissions from Windows if no user or group
has the 'SeDiskOperatorPrivilege' privilege.
Rowland