[v5,0/2] Linux: Fix posix_spawn when user with time namespaces

  The patchset also adds some support to tests the fallback code
to use only use CLONE_VFORK.  It uses unshare directly because
it simpler than add container support.

v5: Use a MAP_SHARED page to communicate error on prepare phase from
    helper process.

Adhemerval Zanella (2):
  support: Add support_enter_time_namespace
  linux: Add fallback for clone failure on posix_spawn (BZ #29115)

 posix/Makefile                         |  16 ++-
 posix/tst-spawn-chdir-timens.c         |   2 +
 posix/tst-spawn-chdir.c                |   7 ++
 posix/tst-spawn-timens.c               |   2 +
 posix/tst-spawn.c                      |   6 ++
 posix/tst-spawn2-timens.c              |   2 +
 posix/tst-spawn2.c                     |   8 ++
 posix/tst-spawn4-timens.c              |   2 +
 posix/tst-spawn4.c                     |  10 +-
 posix/tst-spawn5-timens.c              |   2 +
 posix/tst-spawn5.c                     |  10 +-
 posix/tst-spawn6-timens.c              |   2 +
 posix/tst-spawn6.c                     |  12 ++-
 support/Makefile                       |   1 +
 support/namespace.h                    |   5 +
 support/support_enter_time_namespace.c |  34 ++++++
 sysdeps/unix/sysv/linux/spawni.c       | 141 +++++++++++++++++--------
 17 files changed, 211 insertions(+), 51 deletions(-)
 create mode 100644 posix/tst-spawn-chdir-timens.c
 create mode 100644 posix/tst-spawn-timens.c
 create mode 100644 posix/tst-spawn2-timens.c
 create mode 100644 posix/tst-spawn4-timens.c
 create mode 100644 posix/tst-spawn5-timens.c
 create mode 100644 posix/tst-spawn6-timens.c
 create mode 100644 support/support_enter_time_namespace.c
  

On 5/30/22 13:49, Adhemerval Zanella via Libc-alpha wrote:
> The patchset also adds some support to tests the fallback code
> to use only use CLONE_VFORK.  It uses unshare directly because
> it simpler than add container support.
> 
> v5: Use a MAP_SHARED page to communicate error on prepare phase from
>     helper process.

The current progress is that it seems we may get the upstream Linux kernel
to change the semantics of the time namespace to take effect only after
exec for vfork. If that goes forward we won't need these changes?

I'm trying to determine if these changes constitute a blocker for 2.36.
  

> On 11 Jul 2022, at 12:32, Carlos O'Donell <carlos@redhat.com> wrote:
> 
> On 5/30/22 13:49, Adhemerval Zanella via Libc-alpha wrote:
>> The patchset also adds some support to tests the fallback code
>> to use only use CLONE_VFORK.  It uses unshare directly because
>> it simpler than add container support.
>> 
>> v5: Use a MAP_SHARED page to communicate error on prepare phase from
>>    helper process.
> 
> The current progress is that it seems we may get the upstream Linux kernel
> to change the semantics of the time namespace to take effect only after
> exec for vfork. If that goes forward we won't need these changes?
> 
> I'm trying to determine if these changes constitute a blocker for 2.36.

My understanding is even kernel does change or add a new flag to handle
it, we still have released kernels that might hit this issue.
  

On 7/11/22 12:56, Adhemerval Zanella wrote:
> 
> 
>> On 11 Jul 2022, at 12:32, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 5/30/22 13:49, Adhemerval Zanella via Libc-alpha wrote:
>>> The patchset also adds some support to tests the fallback code
>>> to use only use CLONE_VFORK.  It uses unshare directly because
>>> it simpler than add container support.
>>>
>>> v5: Use a MAP_SHARED page to communicate error on prepare phase from
>>>    helper process.
>>
>> The current progress is that it seems we may get the upstream Linux kernel
>> to change the semantics of the time namespace to take effect only after
>> exec for vfork. If that goes forward we won't need these changes?
>>
>> I'm trying to determine if these changes constitute a blocker for 2.36.
> 
> My understanding is even kernel does change or add a new flag to handle
> it, we still have released kernels that might hit this issue.
 
Thanks. In which case I don't consider this a blocker for 2.36. It's a bug that we can fix
in 2.37 and backport to 2.36 when we've completed the review. I've started looking at these
changes but I think we need more testing in downstream. If we fix this when 2.37 opens we
can start testing it in Fedora Rawhide early, and backport after we know we don't have
further issues.
  

On 18/07/22 23:33, Carlos O'Donell wrote:
> On 7/11/22 12:56, Adhemerval Zanella wrote:
>>
>>
>>> On 11 Jul 2022, at 12:32, Carlos O'Donell <carlos@redhat.com> wrote:
>>>
>>> On 5/30/22 13:49, Adhemerval Zanella via Libc-alpha wrote:
>>>> The patchset also adds some support to tests the fallback code
>>>> to use only use CLONE_VFORK.  It uses unshare directly because
>>>> it simpler than add container support.
>>>>
>>>> v5: Use a MAP_SHARED page to communicate error on prepare phase from
>>>>    helper process.
>>>
>>> The current progress is that it seems we may get the upstream Linux kernel
>>> to change the semantics of the time namespace to take effect only after
>>> exec for vfork. If that goes forward we won't need these changes?
>>>
>>> I'm trying to determine if these changes constitute a blocker for 2.36.
>>
>> My understanding is even kernel does change or add a new flag to handle
>> it, we still have released kernels that might hit this issue.
>  
> Thanks. In which case I don't consider this a blocker for 2.36. It's a bug that we can fix
> in 2.37 and backport to 2.36 when we've completed the review. I've started looking at these
> changes but I think we need more testing in downstream. If we fix this when 2.37 opens we
> can start testing it in Fedora Rawhide early, and backport after we know we don't have
> further issues.
> 

I agree, I have not added it as a 2.36 as blocker although it would be
a good thing to have.
  

On 7/19/22 08:56, Adhemerval Zanella Netto wrote:
> 
> 
> On 18/07/22 23:33, Carlos O'Donell wrote:
>> On 7/11/22 12:56, Adhemerval Zanella wrote:
>>>
>>>
>>>> On 11 Jul 2022, at 12:32, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>
>>>> On 5/30/22 13:49, Adhemerval Zanella via Libc-alpha wrote:
>>>>> The patchset also adds some support to tests the fallback code
>>>>> to use only use CLONE_VFORK.  It uses unshare directly because
>>>>> it simpler than add container support.
>>>>>
>>>>> v5: Use a MAP_SHARED page to communicate error on prepare phase from
>>>>>    helper process.
>>>>
>>>> The current progress is that it seems we may get the upstream Linux kernel
>>>> to change the semantics of the time namespace to take effect only after
>>>> exec for vfork. If that goes forward we won't need these changes?
>>>>
>>>> I'm trying to determine if these changes constitute a blocker for 2.36.
>>>
>>> My understanding is even kernel does change or add a new flag to handle
>>> it, we still have released kernels that might hit this issue.
>>  
>> Thanks. In which case I don't consider this a blocker for 2.36. It's a bug that we can fix
>> in 2.37 and backport to 2.36 when we've completed the review. I've started looking at these
>> changes but I think we need more testing in downstream. If we fix this when 2.37 opens we
>> can start testing it in Fedora Rawhide early, and backport after we know we don't have
>> further issues.
>>
> 
> I agree, I have not added it as a 2.36 as blocker although it would be
> a good thing to have.
 
We'll review this again when 2.37 opens.

Since the details are hidden behind the interfaces in spawni.c it could be backported safely.