public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: DJ Delorie <dj@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [patch v1] Allow for unpriviledged nested containers
Date: Fri, 12 Nov 2021 14:31:53 +0100	[thread overview]
Message-ID: <87sfw1qz3q.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <xnlf1v6ey8.fsf@greed.delorie.com> (DJ Delorie's message of "Wed,  10 Nov 2021 13:30:39 -0500")

* DJ Delorie:

> Florian Weimer <fweimer@redhat.com> writes:
>> Have you tried a bind mount of the existing /proc into the chroot (from
>> the outside of that chroot)?
>
> That's an interesting idea, but the directory it (and /sys, /dev, etc,
> eventually, I suppose) needs to be mounted on doesn't exist until we're
> late into "make check" and rsync'ing the pristine test container to the
> working test container.  And we delete and rebuild that container as
> needed.  It would be a lot of messy logic to pre-mount that.

Huh.  We already do this for various parts of /dev.  I had something
like this in mind (untested):

diff --git a/support/test-container.c b/support/test-container.c
index 94498d3901..ff91a12860 100644
--- a/support/test-container.c
+++ b/support/test-container.c
@@ -1094,6 +1094,13 @@ main (int argc, char **argv)
   trymount (support_srcdir_root, new_srcdir_path);
   trymount (support_objdir_root, new_objdir_path);
 
+  /* It may not be possible to mount /proc directly.  */
+  {
+    char *new_proc = concat (new_root_path, "/proc", NULL);
+    xmkdirp (new_proc);
+    trymount ("/proc", new_proc);
+  }
+
   xmkdirp (concat (new_root_path, "/dev", NULL), 0755);
   devmount (new_root_path, "null");
   devmount (new_root_path, "zero");
@@ -1163,11 +1170,6 @@ main (int argc, char **argv)
 
   maybe_xmkdir ("/tmp", 0755);
 
-  /* Now that we're pid 1 (effectively "root") we can mount /proc  */
-  maybe_xmkdir ("/proc", 0777);
-  if (mount ("proc", "/proc", "proc", 0, NULL) < 0)
-    FAIL_EXIT1 ("Unable to mount /proc: ");
-
   /* We map our original UID to the same UID in the container so we
      can own our own files normally.  */
   UMAP = open ("/proc/self/uid_map", O_WRONLY);

Thanks,
Florian


  reply	other threads:[~2021-11-12 13:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09 23:02 DJ Delorie
2021-11-10  8:23 ` Florian Weimer
2021-11-10 18:30   ` DJ Delorie
2021-11-12 13:31     ` Florian Weimer [this message]
2021-11-15 20:58       ` DJ Delorie
2021-11-15 22:34       ` [patch v2] " DJ Delorie
2021-11-15 22:43       ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sfw1qz3q.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=dj@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).