symlink owner question

[Scott Lovenberg]

On Wed, Apr 26, 2017 at 11:46 PM, Uri Simchoni <uri at samba.org> wrote:
> On 04/26/2017 09:28 PM, Scott Lovenberg via samba-technical wrote:
>> william On Tue, Apr 25, 2017 at 2:10 PM, Uri Simchoni via
>> samba-technical <samba-technical at lists.samba.org> wrote:
>>> Hi,
>>>
>>> Can anyone think of a case where the owner of a symlink matters, that
>>> is, suppose the user creates a symlink via SMB (POSIX extensions), and
>>> the resulting link owned by the wrong user.
>>>
>>> We have such behavior if:
>>> 1. The user is in "admin users" --> smbd runs as root and link owned by
>>> root.
>>> 2. "inherit owner" is enabled - the link has the creator's owner, not
>>> the inherited owner.
>>>
>>> *if* it matters, I can't think of a way of reliably fixing it:
>>> - lchown is a bit racy because the symlink may have been superseded with
>>> something else.
>>> - fchown - the only way I found for opening the symlink is using O_PATH,
>>> and that doesn't support fchown (documented and experimentally verified).
>>>
>>> I have produced a failing test to demonstrate the issue (see attached),
>>> but then got stuck with fixing it :(, so perhaps it's better to declare
>>> it as a non-issue....
>>>
>>> Thoughts?
>>> Uri.
>>
>> Here's an interesting case : DFS symlinks - are there any security
>> implications (especially when the owning group is considered the owner
>> in MS land)?  Another thought - is it possible that a directory with
>> the sticky bit set (or the ACL/XATTR equivalent bits for "Creator
>> Owner") you get into a situation where you cannot modify or delete a
>> file that you created because the ownership changed?  Other than that,
>> I'm drawing a blank on any side effects and those two are probably
>> corner cases at best.
>>
> Thanks!
>
> I don't really know the intricacies of DFS (and access control related
> to it), but looks like you've flagged a corner usability case of
> combining a symbolic link with owner inheritance - if someone sets up a
> drop-box using "inherit owner" and also puts the sticky bit to make that
> box kind of non-modify, he'll fail deleting symlinks?

I believe that to be the case if symlinks (everything is just a file,
right? :) ) behave as regular files do.  I ran into this issue with an
older version of Microsoft Office where there's a bit of "clever" temp
file creation and then renaming/overwriting of Excel files.  I think
in this case if I'm understanding your original question correctly,
you'll not even need the "inherit owner" bit for the unexpected
behavior since the owner is changed to "root" upon creation of the
symlink.  That was just the way I knew to trigger the corner case when
the owner wasn't changed on creation.

Technically speaking, the corner case behavior is correct when the
configuration specifies those parameters (inherit owner and only let
owner delete), but I think in your case it would happen without a
configuration where the Samba configuration/file system configuration
haven't explicitly setup those conditions completely (ie, you only
need to set the sticky bit, not the inheritance part).  I think I may
have ended up allowing group ownership on the drop box dir and setting
the owning group to "users".  It's been many years, so I may be a bit
fuzzy on the details, so take this all with that in mind. :)


-- 
Peace and Blessings,
-Scott.