share-level permissions and SYSTEM_SECURITY to files and dirs failing even though token has SeSecurityPrivilege

[Richard Sharpe]

On Tue, May 15, 2012 at 5:11 PM, Jeremy Allison <jra at samba.org> wrote:
> On Tue, May 15, 2012 at 03:38:37PM -0700, Richard Sharpe wrote:
>> Hi,
>>
>> in smbd_check_access_rights we first check if the share permissions
>> allow the mode of access. This fails of the caller asked for
>> SYSTEM_SECURITY and no further check is made.
>>
>> However, if the logged in user's token contains SeSecurityPrivilege
>> and rejected_share_access was only SYSTEM_SECURITY, then I believe
>> that the requested operation should be allowed to continue to further
>> checks.
>>
>> What say ye?
>
> Errrr. Yeah. Sounds about right to me :-).

OK, but in thinking about this some more, I think the correct fix is a
slight restructuring of the current code.

We currently have share_rejected_access, which is checked first up,
and we error out immediately if any bits are rejected at that point.

Rather than duplicate the privilege checks that are in
se_access_check, I would rather use those share_rejected_bits to feed
into rejected_mask and have se_access_check pull those in to see if
privileges override them ...

I guess I should look at how Windows handles this. The algorithm is
available, at least.

The issue came up because xcopy /X with a SACL does really weird
things if it cannot get access to the parent directory with
SYSTEM_SECURITY but can get access to the newly created file with that
access mode. (It stores the SACL but creates an empty DACL :-)

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)