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

On Tue, May 04, 2021 at 02:44:36PM +0200, Ralph Boehme via samba
wrote:
>Am 5/4/21 um 6:34 AM schrieb Jorgen Lundman via samba:
>>...
>>
>>create_file: NT_STATUS_ACCESS_DENIED
>>
>>Running truss on smb to find out what actually goes wrong, it appears
>>to be:
>>
>>streams_xattr_open called for /proc/self/fd/11 with flags 0x81 
>>6036/1:         write(1, " s t r e a m s _ x a t t".., 63)    
= 63
>>6036/1:         open("/proc/self/fd/11", O_WRONLY|O_NONBLOCK)
>>Err#13 EACCES [proc_owner] catia_fetch_fsp_post_next: Called from
>>[catia_openat] 6036/1:         write(1, " c a t i a _ f e t c h
_"..,
>>54)      = 54
>>
>>Which is presumably OmniOS related, in that it is trying to open the
>>/proc/self/ as a different uid to the process.
>
>Can you elaborate on that please so I can better understand why the
>open() fails with EACCES?
>
>Particularly I don't understand what you mean with "... trying to
open
>the /proc/self/ as a different uid to the process."
>
>Typically Samba would to this open() syscall impersonating the
>authenticated user (ie set effective uid, gid and auxiliary groups set
>to the values of the underlying OS account).
>
>>Can I tell Smb to not use /proc/self, and instead use regular paths?
>
>No currently there's no way to disable this other by configuration.
>There's a general runtime check that verifies /proc/self/fd is usable by
>calling stat() on /proc/self/fd/0 (iirc), looks like this is not fine
>grained enough to cover stupid OSes.
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

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."


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. There's just too many areas for legacy UNIXes to "improve"
things when re-inventing the Linux semantics :-(.

Or maybe it's Linux "improving" the semantics it copies from
legacy UNIXes :-). Either way, they never seem to have the same
behavior :-(.

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>