From: Philipp Wendler <ml-PRuqubkS1MrCxoAYUeDZubNAH6kLmebB@public.gmane.org>
To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: Using overlayfs in (unprivileged) namespace
Date: Mon, 15 Feb 2016 13:30:15 +0100 [thread overview]
Message-ID: <56C1C4D7.8030406@philippwendler.de> (raw)
In-Reply-To: <56C1BAE2.30209-6AxghH7DbtA@public.gmane.org>
Dear Nikolay,
thank you for your answer.
Am 15.02.2016 um 12:47 schrieb Nikolay Borisov:
> On 02/15/2016 01:04 PM, Philipp Wendler wrote:
>> $ ./userns_child_exec -m -U -z bash
>>
>> Then execute the following commands:
>>
>> mkdir /tmp/namespace-overlay
>> cd /tmp/namespace-overlay
>> mkdir mount lower upper work
>> touch lower/test
>> mount -t overlayfs n -o lowerdir=lower,upperdir=upper,workdir=work mount
>> rm mount/test
>>
>> The last command gives:
>>> rm: cannot remove 'mount/test': Operation not permitted
>>
>> This fails even if /tmp does not have "nodev" set (with "nodev" it would
>> be expected to fail of course).
>> Interestingly, it even fails if I start userns_child_exec as root,
>> not sure why.
>> Outside namespaces everything works as expected.
>
> Wouldn't using the device cgroup with the respective major/minor numbers
> allowed rectify the situation?
I am not sure how.
I have no special setup for the devices cgroup.
The file devices.list of the cgroup in which my process is contains
"a *:* rwm".
So I think the devices cgroup would already allow me to create that
device node, and I have no way to grant additional permissions with the
cgroup, right?
At least that is how I understand the documentation for the devices cgroup.
> Also, have you done any tracing trying to
> figure out where exactly is this failing? E.g. using ftrace?
Sorry, no, I don't know how to do this.
I have looked into ftrace now, but I didn't find a way how to see which
function is responsible for letting the rm fail.
The kernel documentation on ftrace is quite overwhelming, so maybe I
have missed something.
Do you have by chance a more specific pointer to what would help me?
Greetings, Philipp
next prev parent reply other threads:[~2016-02-15 12:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 11:04 Using overlayfs in (unprivileged) namespace Philipp Wendler
[not found] ` <56C1B0C6.6080806-PRuqubkS1MrCxoAYUeDZubNAH6kLmebB@public.gmane.org>
2016-02-15 11:47 ` Nikolay Borisov
[not found] ` <56C1BAE2.30209-6AxghH7DbtA@public.gmane.org>
2016-02-15 12:30 ` Philipp Wendler [this message]
[not found] ` <56C1C4D7.8030406-PRuqubkS1MrCxoAYUeDZubNAH6kLmebB@public.gmane.org>
2016-02-15 12:37 ` Nikolay Borisov
[not found] ` <56C1C674.3030705-6AxghH7DbtA@public.gmane.org>
2016-02-15 14:46 ` Philipp Wendler
2016-02-15 18:18 ` Serge Hallyn
2016-02-15 18:47 ` Philipp Wendler
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=56C1C4D7.8030406@philippwendler.de \
--to=ml-pruqubks1mrcxoayuedzubnah6klmebb@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox