clone tests fail on CentOS 7

  • Open
  • quality assurance status badge
Details
2 participants
  • Paul Garlick
  • zimoun
Owner
unassigned
Submitted by
Paul Garlick
Severity
normal
P
P
Paul Garlick wrote on 26 Jun 2018 16:16
(address . bug-guix@gnu.org)
1530022595.3353.22.camel@tourbillion-technology.com
Hi Guix,

Running 'make check' in the guix source tree on a CentOS 7 system
results in 15 FAILS:

tests/containers.log: 9 FAILS
tests/syscalls.log: 3 FAILS
tests/guix-environment-container.log: 1 FAIL
tests/guix-pack.log: 1 FAIL
tests/pack.log: 1 FAIL

Referring to bug#24108, the cause may be that the clone-related tests
are being executed instead of being skipped. 

The output of 'uname -srv' is:

Linux 3.10.0-862.3.3.el7.x86_64 #1 SMP Fri Jun 15 04:15:27 UTC 2018

Files:
a)  '/proc/self/ns/user' exists
b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.

On CentOS 7 I believe user namespaces are supported but disabled by
default.  The output of 'cat /proc/sys/user/max_user_namespaces' is
'0'.

Perhaps the 'perform-container-tests?' logic should include an extra
check for the default, disabled case to ensure that the tests are
skipped.

Attached are the log files, except 'guix-pack.log' (~100MB) and
'pack.log' (~7MB).

Best regards,

Paul.
Attachment: containers.log
accepted connection from pid 1029, user paul
+ set -e
+ guix environment --version
guix environment (GNU Guix) 0.14.0.6752-a87cb
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ guile -c '((@@ (guix scripts environment) assert-container-features))'
+ tmpdir=t-guix-environment-1039
+ trap 'rm -r "$tmpdir"' EXIT
+ mkdir t-guix-environment-1039
+ guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
accepted connection from pid 1054, user paul
guix environment: error: clone: 2080505873: Invalid argument
+ test 1 = 42
+ rm -r t-guix-environment-1039
./test-env: line 1: 1028 Terminated "/data/paul/sourceCode/guix/pre-inst-env" "/data/paul/sourceCode/guix/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
FAIL tests/guix-environment-container.sh (exit status: 1)
Attachment: syscalls.log
Z
Z
zimoun wrote on 1 Dec 2020 19:12
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)(address . 31977@debbugs.gnu.org)
86ft4pv1ik.fsf@gmail.com
Hi Paul,

This old bug #31977 is about an issue on your CentOS 7 machine. Is it
still relevant?


On Tue, 26 Jun 2018 at 15:16, Paul Garlick <pgarlick@tourbillion-technology.com> wrote:

Toggle quote (12 lines)
> Running 'make check' in the guix source tree on a CentOS 7 system
> results in 15 FAILS:
>
> tests/containers.log: 9 FAILS
> tests/syscalls.log: 3 FAILS
> tests/guix-environment-container.log: 1 FAIL
> tests/guix-pack.log: 1 FAIL
> tests/pack.log: 1 FAIL
>
> Referring to bug#24108, the cause may be that the clone-related tests
> are being executed instead of being skipped.

Note that bug#24108 had been closed couple of months ago:

Toggle snippet (11 lines)
From: Ludovic Courtès <ludo@gnu.org>
Subject: control message for bug #24108
To: control@debbugs.gnu.org, 24108@debbugs.gnu.org
Date: Thu, 09 Jul 2020 15:58:27 +0200 (20 weeks, 5 days, 4 hours ago)

tags 24108 notabug
close 24108
quit


Toggle quote (24 lines)
> The output of 'uname -srv' is:
>
> Linux 3.10.0-862.3.3.el7.x86_64 #1 SMP Fri Jun 15 04:15:27 UTC 2018
>
> Files:
> a) '/proc/self/ns/user' exists
> b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.
>
> On CentOS 7 I believe user namespaces are supported but disabled by
> default. The output of 'cat /proc/sys/user/max_user_namespaces' is
> '0'.
>
> Perhaps the 'perform-container-tests?' logic should include an extra
> check for the default, disabled case to ensure that the tests are
> skipped.
>
> Attached are the log files, except 'guix-pack.log' (~100MB) and
> 'pack.log' (~7MB).
>
> Best regards,
>
> Paul.


Feel free to close it or report more information about the current
status.


Thanks,
simon
P
P
Paul Garlick wrote on 2 Dec 2020 19:08
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 31977@debbugs.gnu.org)
85c5c82b887d921b3395a1d7a240b5c9de46c89b.camel@tourbillion-technology.com
Hi Simon,

On Tue, 2020-12-01 at 19:12 +0100, zimoun wrote:
Toggle quote (3 lines)
> This old bug #31977 is about an issue on your CentOS 7 machine. Is
> it still relevant?

Yes, this bug still exists.

However, I have just tested a fix:

--- a/gnu/build/linux-container.scm
+++ b/gnu/build/linux-container.scm
@@ -44,7 +44,7 @@
(let ((userns-file "/proc/sys/kernel/unprivileged_userns_clone"))
(if (file-exists? userns-file)
(eqv? #\1 (call-with-input-file userns-file read-char))
- #t)))
+ #f)))
(define (setgroups-supported?)
"Return #t if the setgroups proc file, introduced in Linux-libre
3.19,

This ensures that tests are skipped if user namespaces are not enabled
for unprivileged users.

Best regards,

Paul.
P
P
Paul Garlick wrote on 3 Dec 2020 17:34
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 31977@debbugs.gnu.org)
1317d9cf798a52364abd5905c17f207e8d9e31ed.camel@tourbillion-technology.com
Hi Simon,

I have pushed the fix as 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e.

Best regards,

Paul.
P
P
Paul Garlick wrote on 3 Dec 2020 17:40
(address . control@debbugs.gnu.org)
c87c2506d8f7454a7ae815500855d1db1cfda888.camel@tourbillion-technology.com
close 31977
quit
Z
Z
zimoun wrote on 7 Dec 2020 01:54
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
86mtyq8mh0.fsf@gmail.com
Hi Paul,

On Thu, 03 Dec 2020 at 16:34, Paul Garlick <pgarlick@tourbillion-technology.com> wrote:

Toggle quote (2 lines)
> I have pushed the fix as 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e.

Apparently people are complaining [1,2]. Well, I do not understand what it
breaks but Marius reverted the commit (see #45066) so I am reopening the
issue.



All the best,
simon

2:
Z
Z
zimoun wrote on 19 Dec 2020 10:26
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
867dpervs5.fsf@gmail.com
Hi Paul,

Since the fix 8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e breaks
linux-libre kernel on Guix System, because of [1], quote:

Well, it is expected. And now all is clear. Explanations starting
there:


Quickly said, the initial code was assuming Debian-like kernel patches
as Vagrant reported and this is not in the linux-libre source code with
a wrong Guix error message.

One bug is still there. :-)



If I understand well your message:

Files:
a) '/proc/self/ns/user' exists
b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.

from your initial report, it is the same problem as linux-libre:
somehow, the assumption of '/proc/sys/kernel/unprivileged_userns_clone'
is Debian-like and not shared.

So, it could be nice to have a good story for that. :-)


All the best,
simon
P
P
Paul Garlick wrote on 21 Dec 2020 16:29
(name . zimoun)(address . zimon.toutoune@gmail.com)
8738bc1a86f5af35a9aa79e3e7da0e4fac15348e.camel@tourbillion-technology.com
Hi Simon,

Toggle quote (6 lines)
> If I understand well your message:
>
> Files:
> a) '/proc/self/ns/user' exists
> b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.

Yes, this is the case on CentOS.

So testing for the existence of the unprivileged_userns_clone file is
an insufficent test for unprivileged user namespaces. We have learnt
that trying to create the file as a dummy file does not work, since the
/proc/sys/kernel directory is read-only even for root.

So the current 'unprivileged-user-namespace-supported?' function in
gnu/build/linux-container.scm really only works for Debian-derived
systems. Other systems, that co not create the
unprivileged_userns_clone file, differ in their default configurations.
CentOS, for example, disables the feature. However, Guix System
enables it.

It has been suggested that the feature itself should be tested, instead
of relying on the /proc filesystem. This could well be a better idea
and I gather from the thread that this idea is being worked on. I can
test on CentOS when a new patch is available.

Best regards,

Paul.
Z
Z
zimoun wrote on 8 Oct 2022 16:30
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
8635bytmjh.fsf@gmail.com
Hi Paul,

It is about this old bug#31977 [1]. Well, I have lost the status about
this and since I am using Debian with unprivileged_userns_clone, I am
not annoyed enough. ;-)



On Mon, 21 Dec 2020 at 15:29, Paul Garlick <pgarlick@tourbillion-technology.com> wrote:

Toggle quote (5 lines)
> It has been suggested that the feature itself should be tested, instead
> of relying on the /proc filesystem. This could well be a better idea
> and I gather from the thread that this idea is being worked on. I can
> test on CentOS when a new patch is available.

Is it still an issue for you?


Cheers,
simon
Z
Z
zimoun wrote on 3 Nov 2022 10:47
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)
86sfj0bc8s.fsf@gmail.com
Hi Paul,

On Sat, 08 Oct 2022 at 16:30, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (17 lines)
> On Mon, 21 Dec 2020 at 15:29, Paul Garlick <pgarlick@tourbillion-technology.com> wrote:

> It is about this old bug#31977 [1]. Well, I have lost the status about
> this and since I am using Debian with unprivileged_userns_clone, I am
> not annoyed enough. ;-)
>
> 1: <http://issues.guix.gnu.org/issue/31977>
>
>
>
>> It has been suggested that the feature itself should be tested, instead
>> of relying on the /proc filesystem. This could well be a better idea
>> and I gather from the thread that this idea is being worked on. I can
>> test on CentOS when a new patch is available.
>
> Is it still an issue for you?

Friendly ping. :-)


Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 31977@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 31977
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch