From: Richard Weinberger <richard-S6VGOU4v5edDinCvNWH78Q@public.gmane.org>
To: Enrico Weigelt <lkml-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
Cc: Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: plan9 semantics on Linux - mount namespaces
Date: Wed, 14 Feb 2018 15:19:24 +0100 [thread overview]
Message-ID: <2050418.Dl5pXkWGsk@blindfold> (raw)
In-Reply-To: <a2a6f189-008e-38f2-afcb-b9393d8d440a-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
Am Mittwoch, 14. Februar 2018, 15:03:55 CET schrieb Enrico Weigelt:
> On 14.02.2018 13:53, Richard Weinberger wrote:
> > It does what you ask it for. > Also see the --setgroups switch.> AFAICT
> > --setgroups=deny is the new
> default, then your command line should just> work. Maybe your unshare
> tool is too old.
> Also doesn't help:
>
> daemon@alphabox:~ unshare -U -r --setgroups=deny
> unshare: can't open '/proc/self/setgroups': Permission denied
Works here(tm).
Can you debug it? Maybe we miss something obvious.
> >> What I'd like to achieve is that processes can manipulate their private
> >> >> namespace at will and mount other filesystems (primarily 9p and
> fuse).>>>> For that, I need to get rid of setuid (and per-file caps) for
> these>> private namespaces.>
>
> > This is exactly why we have the user namespace.
> > In the user namespace you can create your own mount namespace and do
> > (almost) whatever you want.
>
> What's the exact relation between user and mnt namespace ?
> Why do I need an own user ns for private mnt ns ? (except for the suid
> bit, which I wanna get rid of anyways).
mount related system calls are root-only. Therefore you need the user
namespace to become a root in your own little world. :)
Thanks,
//richard
--
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@sigma-star.at>
To: Enrico Weigelt <lkml@metux.net>
Cc: Aleksa Sarai <asarai@suse.de>,
Linux Containers <containers@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: plan9 semantics on Linux - mount namespaces
Date: Wed, 14 Feb 2018 15:19:24 +0100 [thread overview]
Message-ID: <2050418.Dl5pXkWGsk@blindfold> (raw)
In-Reply-To: <a2a6f189-008e-38f2-afcb-b9393d8d440a@metux.net>
Am Mittwoch, 14. Februar 2018, 15:03:55 CET schrieb Enrico Weigelt:
> On 14.02.2018 13:53, Richard Weinberger wrote:
> > It does what you ask it for. > Also see the --setgroups switch.> AFAICT
> > --setgroups=deny is the new
> default, then your command line should just> work. Maybe your unshare
> tool is too old.
> Also doesn't help:
>
> daemon@alphabox:~ unshare -U -r --setgroups=deny
> unshare: can't open '/proc/self/setgroups': Permission denied
Works here(tm).
Can you debug it? Maybe we miss something obvious.
> >> What I'd like to achieve is that processes can manipulate their private
> >> >> namespace at will and mount other filesystems (primarily 9p and
> fuse).>>>> For that, I need to get rid of setuid (and per-file caps) for
> these>> private namespaces.>
>
> > This is exactly why we have the user namespace.
> > In the user namespace you can create your own mount namespace and do
> > (almost) whatever you want.
>
> What's the exact relation between user and mnt namespace ?
> Why do I need an own user ns for private mnt ns ? (except for the suid
> bit, which I wanna get rid of anyways).
mount related system calls are root-only. Therefore you need the user
namespace to become a root in your own little world. :)
Thanks,
//richard
--
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
next prev parent reply other threads:[~2018-02-14 14:19 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 22:12 plan9 semantics on Linux - mount namespaces Enrico Weigelt
2018-02-13 22:19 ` Enrico Weigelt
[not found] ` <5633d335-3926-d98f-d6d7-948b1e2a0b2c-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-13 22:27 ` Aleksa Sarai
2018-02-13 22:27 ` Aleksa Sarai
2018-02-14 0:01 ` Enrico Weigelt
[not found] ` <39b08c53-3449-3164-c1b1-44ac587dd4ea-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 4:54 ` Aleksa Sarai
2018-02-14 4:54 ` Aleksa Sarai
2018-02-14 10:18 ` Enrico Weigelt
2018-02-14 10:24 ` Aleksa Sarai
2018-02-14 11:27 ` Enrico Weigelt
2018-02-14 11:27 ` Enrico Weigelt
[not found] ` <24ddea73-5c84-e098-caae-8a4c14834cbd-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 11:30 ` Richard Weinberger
2018-02-14 11:30 ` Richard Weinberger
[not found] ` <CAFLxGvzxLP_UTQbwEY99bQfyftWzZHwaOP+WrzJ8099EKtbVLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-14 12:38 ` Enrico Weigelt
2018-02-14 12:38 ` Enrico Weigelt
[not found] ` <4864d279-9a3f-eaf4-c297-ea34be604e41-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 12:53 ` Richard Weinberger
2018-02-14 12:53 ` Richard Weinberger
2018-02-14 14:03 ` Enrico Weigelt
2018-02-14 14:03 ` Enrico Weigelt
[not found] ` <a2a6f189-008e-38f2-afcb-b9393d8d440a-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 14:19 ` Richard Weinberger [this message]
2018-02-14 14:19 ` Richard Weinberger
2018-02-14 15:02 ` Enrico Weigelt
2018-02-14 15:02 ` Enrico Weigelt
[not found] ` <4f620eb7-c00c-487b-2e06-8cc4c97af38c-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 15:17 ` Richard Weinberger
2018-02-14 15:17 ` Richard Weinberger
2018-02-14 17:21 ` Enrico Weigelt
2018-02-14 17:50 ` Richard Weinberger
2018-02-14 18:01 ` Enrico Weigelt
[not found] ` <794929ce-0ecb-4c93-d51e-e94fcf749cfa-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 18:12 ` Richard Weinberger
2018-02-14 18:12 ` Richard Weinberger
2018-02-14 18:32 ` Enrico Weigelt
2018-02-14 18:32 ` Enrico Weigelt
2018-02-14 18:01 ` Enrico Weigelt
[not found] ` <e924b563-44c6-d678-a6cc-1181f4b820d5-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 17:50 ` Richard Weinberger
2018-02-14 20:39 ` Aleksa Sarai
2018-02-14 20:39 ` Aleksa Sarai
2018-02-14 17:21 ` Enrico Weigelt
[not found] ` <9c097fd9-3035-d5be-a829-fc18e7734f18-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-14 10:24 ` Aleksa Sarai
2018-02-14 10:18 ` Enrico Weigelt
2018-02-14 0:01 ` Enrico Weigelt
2018-02-16 18:26 ` Eric W. Biederman
2018-02-16 18:26 ` Eric W. Biederman
[not found] ` <0f058286-a432-379b-f559-f2fe713807ab-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.org>
2018-02-13 22:19 ` Enrico Weigelt
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=2050418.Dl5pXkWGsk@blindfold \
--to=richard-s6vgou4v5eddincvnwh78q@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lkml-EcKl7qYKIbxeoWH0uzbU5w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.