samba - Apr 2020 - samba 4.12 build on hp-ux unsupported system calls

Hi Team,

We are having compile/linking time warning due unsatisfied system calls and
macros.
We have checked and confirm that these are not supported by hp-ux kernel and
enabling them will require changes in VFS layer and physical filesystem.

Unsatisfied system calls

*        renameat

*        symlinkat

*        linkat

*        unlinkat

*        readlinkat

*        mkdirat

Undefined MACRO's

*        AT_REMOVEDIR

*        AT_FDCWD

These system calls have been added newly in samba 4.12.

Please provide workaround/patch to use older syscalls like mkdir,readlink,unlink
etc within samba 4.12.

Regards,
Arjit

On Wed, Apr 08, 2020 at 09:58:26AM +0000, Kumar, Arjit (SSTO) via samba
wrote:
> Hi Team,
> 
> We are having compile/linking time warning due unsatisfied system calls and
macros.
> We have checked and confirm that these are not supported by hp-ux kernel
and enabling them will require changes in VFS layer and physical filesystem.
> 
> Unsatisfied system calls
> 
> *        renameat
> 
> *        symlinkat
> 
> *        linkat
> 
> *        unlinkat
> 
> *        readlinkat
> 
> *        mkdirat
> 
> Undefined MACRO's
> 
> *        AT_REMOVEDIR
> 
> *        AT_FDCWD
> 
> These system calls have been added newly in samba 4.12.
> 
> Please provide workaround/patch to use older syscalls like
mkdir,readlink,unlink etc within samba 4.12.
I'm afraid that can't be done.

It's not possible to write a secure path-safe
modern application without the XXXXat() calls.

That's why we're moving to require them.

HPUX kernel will have to add these calls,
or the HPUX ecosystem can't be maintained
going forward. Sorry for the bad news :-(.

Either that or you'll have to add mappings
in your libc to emulate these calls, but
that won't be secure I'm afraid.

Am 4/8/20 um 11:58 AM schrieb Kumar, Arjit (SSTO) via
samba:
> Please provide workaround/patch to use older syscalls like
mkdir,readlink,unlink etc within samba 4.12.
as explained by Jeremy, this is not going to happen.

What you could also do is implement a custom VFS module that implements
the *at functions using the non-at variants. But is going to throw away
the added security that *at functions give.

-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: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20200408/b72cdf61/signature.sig>

Hi Team,
>>  It's not possible to write a secure path-safe modern application
without the XXXXat() calls.
Are you referring to secure path-safe applications due to below reasons
mentioned in https://linux.die.net/man/2/openat.

openat() and other similar system calls suffixed "at" are supported
for two reasons.

First, openat() allows an application to avoid race conditions that could occur
when using open(2) to open files in directories other than the current working
directory. These race conditions result from the fact that some component of the
directory prefix given to open(2) could be changed in parallel with the call to
open(2). Such races can be avoided by opening a file descriptor for the target
directory, and then specifying that file descriptor as the dirfd argument of
openat().

Second, openat() allows the implementation of a per-thread "current working
directory", via file descriptor(s) maintained by the application. (This
functionality can also be obtained by tricks based on the use of
/proc/self/fd/dirfd, but less efficiently.)
>> Either that or you'll have to add mappings in your libc to emulate
these calls, but that won't be secure I'm afraid.
Earlier samba versions 4.11 and previous uses normal calls instead of *at()
calls.
Is this change done to fix any specific security issue, which earlier version
still have ?

If not then If we create wrappers and keep using older sys calls what type of
issues may occur ?
  
Regards,
Arjit

-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Wednesday, April 8, 2020 9:41 PM
To: Kumar, Arjit (SSTO) <arjit.kumar at hpe.com>
Cc: samba at lists.samba.org
Subject: Re: [Samba] samba 4.12 build on hp-ux unsupported system calls

On Wed, Apr 08, 2020 at 09:58:26AM +0000, Kumar, Arjit (SSTO) via samba
wrote:
> Hi Team,
> 
> We are having compile/linking time warning due unsatisfied system calls and
macros.
> We have checked and confirm that these are not supported by hp-ux kernel
and enabling them will require changes in VFS layer and physical filesystem.
> 
> Unsatisfied system calls
> 
> *        renameat
> 
> *        symlinkat
> 
> *        linkat
> 
> *        unlinkat
> 
> *        readlinkat
> 
> *        mkdirat
> 
> Undefined MACRO's
> 
> *        AT_REMOVEDIR
> 
> *        AT_FDCWD
> 
> These system calls have been added newly in samba 4.12.
> 
> Please provide workaround/patch to use older syscalls like
mkdir,readlink,unlink etc within samba 4.12.
I'm afraid that can't be done.

It's not possible to write a secure path-safe modern application without the
XXXXat() calls.

That's why we're moving to require them.

HPUX kernel will have to add these calls, or the HPUX ecosystem can't be
maintained going forward. Sorry for the bad news :-(.

Either that or you'll have to add mappings in your libc to emulate these
calls, but that won't be secure I'm afraid.