[PATCH] system: Do not add "--disable-chroot" to containers.

  • Open
  • quality assurance status badge
Details
2 participants
  • Andreas Enge
  • Ludovic Courtès
Owner
unassigned
Submitted by
Andreas Enge
Severity
normal
A
A
Andreas Enge wrote on 14 May 13:50 +0200
(address . guix-patches@gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)
67f49b23cfe3755c6802e2fc3351ef3cf0dcdfda.1715687434.git.andreas@enge.fr
The rationale for these lines is that they enable non-privileged docker
containers. But I would like to create a privileged container with
chroot (in an openshift environment, where I suppose this environment
does additional encapsulation to enforce security), which these lines
prevent.

Users can still add the option. Alternatively, we could add an additional
field "chroot? (default: #t)" to guix-configuration.

Andreas



* gnu/system/linux-container.scm (containerized-operating-system): Do not
add "--disable-chroot".

Change-Id: I1eff9aa0d02d6e53bd4e42f3aeb07d0ab42616a8
---
gnu/system/linux-container.scm | 11 -----------
1 file changed, 11 deletions(-)

Toggle diff (26 lines)
diff --git a/gnu/system/linux-container.scm b/gnu/system/linux-container.scm
index c780b68fba..2fc54a8121 100644
--- a/gnu/system/linux-container.scm
+++ b/gnu/system/linux-container.scm
@@ -159,17 +159,6 @@ (define* (containerized-operating-system os mappings
(nscd-configuration
(inherit (service-value s))
(caches %nscd-container-caches))))
- ((eq? guix-service-type (service-kind s))
- ;; Pass '--disable-chroot' so that
- ;; guix-daemon can build thing even in
- ;; Docker without '--privileged'.
- (service guix-service-type
- (guix-configuration
- (inherit (service-value s))
- (extra-options
- (cons "--disable-chroot"
- (guix-configuration-extra-options
- (service-value s)))))))
(else s)))
(operating-system-user-services os))))
(file-systems (append (map mapping->fs

base-commit: a682ddd70846d488cfbd82d65e8566ec6739813c
--
2.41.0
L
L
Ludovic Courtès wrote on 31 May 14:01 +0200
(name . Andreas Enge)(address . andreas@enge.fr)(address . 70933@debbugs.gnu.org)
87mso6rxzz.fsf@gnu.org
Hi,

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (9 lines)
> The rationale for these lines is that they enable non-privileged docker
> containers. But I would like to create a privileged container with
> chroot (in an openshift environment, where I suppose this environment
> does additional encapsulation to enforce security), which these lines
> prevent.
>
> Users can still add the option. Alternatively, we could add an additional
> field "chroot? (default: #t)" to guix-configuration.

[...]

Toggle quote (5 lines)
> - ((eq? guix-service-type (service-kind s))
> - ;; Pass '--disable-chroot' so that
> - ;; guix-daemon can build thing even in
> - ;; Docker without '--privileged'.

This is tricky, I’m not sure how to provide defaults that works in most
common setups while still allowing the use of privileged Docker
containers as in your case.

I think the current default is good because it’s the common case, but I
agree that we need to find a way to override it.

Thoughts?

Ludo’.
A
A
Andreas Enge wrote on 31 May 16:26 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 70933@debbugs.gnu.org)
ZlneMuuPEfakaS47@jurong
Am Fri, May 31, 2024 at 02:01:36PM +0200 schrieb Ludovic Courtès:
Toggle quote (12 lines)
> Andreas Enge <andreas@enge.fr> skribis:
> > The rationale for these lines is that they enable non-privileged docker
> > containers. But I would like to create a privileged container with
> > chroot (in an openshift environment, where I suppose this environment
> > does additional encapsulation to enforce security), which these lines
> > prevent.
> > Users can still add the option. Alternatively, we could add an additional
> > field "chroot? (default: #t)" to guix-configuration.
> This is tricky, I’m not sure how to provide defaults that works in most
> common setups while still allowing the use of privileged Docker
> containers as in your case.

The problem with a default is that apparently, for containers we want #f,
for real machines we want #t as the default; and then it should be
overridable. The only solution I see is to use a ternary value,
allowing chroot? to be #f, #t or 'default, with the last one, you guess it,
being the default. It would be replaced by #f or #t depending on whether
we are in a container or not.

I had considered it when suggesting the patch, but found it a bit too much
shepherding; I still think that "chroot? (default: #t)" would be enough.

Andreas
L
L
Ludovic Courtès wrote 22 hours ago
(name . Andreas Enge)(address . andreas@enge.fr)(address . 70933@debbugs.gnu.org)
87h6dhca5s.fsf@gnu.org
Hi!

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (20 lines)
> Am Fri, May 31, 2024 at 02:01:36PM +0200 schrieb Ludovic Courtès:
>> Andreas Enge <andreas@enge.fr> skribis:
>> > The rationale for these lines is that they enable non-privileged docker
>> > containers. But I would like to create a privileged container with
>> > chroot (in an openshift environment, where I suppose this environment
>> > does additional encapsulation to enforce security), which these lines
>> > prevent.
>> > Users can still add the option. Alternatively, we could add an additional
>> > field "chroot? (default: #t)" to guix-configuration.
>> This is tricky, I’m not sure how to provide defaults that works in most
>> common setups while still allowing the use of privileged Docker
>> containers as in your case.
>
> The problem with a default is that apparently, for containers we want #f,
> for real machines we want #t as the default; and then it should be
> overridable. The only solution I see is to use a ternary value,
> allowing chroot? to be #f, #t or 'default, with the last one, you guess it,
> being the default. It would be replaced by #f or #t depending on whether
> we are in a container or not.

Making it a ternary value sounds like a good idea, indeed. #t, #f, and
'default sounds like a good choice to me.

Thanks!

Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 70933
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