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

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.

Cheers!
-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/5a8ea759/OpenPGP_signature.sig>

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 :-(.