samba - May 2021 - /proc/self open fails with proc_owner Was: Time-machine replies with 17: File Exists

Am 5/4/21 um 7:02 PM schrieb Jeremy Allison:
> Here's the page with the Solaris docs on /proc/self/fd.
> 
> https://docs.oracle.com/cd/E19253-01/816-5174/proc-4/index.html
Oh, thanks for digging this up!
> Note:
> 
> fd
> 
> A directory containing references to the open files of the process.
> Each entry is a decimal number corresponding to an open file descriptor
> in the process.
> 
> If an entry refers to a regular file, it can be opened with normal
> file system semantics but, to ensure that the controlling process
> cannot gain greater access than the controlled process, with no
> file access modes other than its read/write open modes in the
> controlled process. If an entry refers to a directory, it can
> be accessed with the same semantics as /proc/pid/cwd. An attempt
> to open any other type of entry fails with EACCES."
hm, but what is this controlled and controlling process nonsense about? 
They're both the same process here. The only thing I can imagine is that 
you cannot reopen with a different mode then the original open -- which 
is totally braindead. But anyway...
> I'm starting to think that we will never be able to depend on
> the correct semantics for /proc/self/fd for anything other than
> Linux.
Sure, that's expected, Linux has taken over anyway. We just have to 
tweak our runtime detection a bit.

I'll try to code something up after SambaXP.

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20210504/9fc1cff4/OpenPGP_signature.sig>

> hm, but what is this controlled and controlling process nonsense about?
They're both the same process here. The only thing I can imagine is that you
cannot reopen with a different mode then the original open -- which is totally
braindead. But anyway...
> 
If we are curious, we die in:

dtrace -n 'secpolicy_proc_access:entry {printf("uid %u, euid %d, gid
%d, egid %d", $uid, $euid, $gid, $egid);} '  -n
'secpolicy_proc_access:return {printf("%d", arg1);}?


  7  14124      secpolicy_proc_access:entry uid 0, euid 0, gid 0, egid 0
  7  14125     secpolicy_proc_access:return 13


int
secpolicy_proc_access(const cred_t *scr)
{
        return (PRIV_POLICY(scr, PRIV_PROC_OWNER, B_FALSE, EACCES, NULL));
}

I attempted to award proc_owner to root (even though it already has All) but I
seem unable to make it get past this check.