From: "Ángel González" <ingenit@zoho.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
"Karel Zak" <kzak@redhat.com>,
util-linux@vger.kernel.org
Subject: Re: [PATCH 2/5] nsenter: add --all meaning all namespaces and cwd and root
Date: Mon, 28 Jan 2013 21:41:51 +0100 [thread overview]
Message-ID: <5106E28F.7040901@zoho.com> (raw)
In-Reply-To: <874ni22frn.fsf@xmission.com>
On 28/01/13 03:38, Eric W. Biederman wrote:
> Ángel González <ingenit@zoho.com> writes:
>> Except that when you are distributing such script (eg. an init-like
>> script), your shell script will need to add code detecting which
>> namespaces the kernel supports (and adding appropiate flags to nsenter)
>> and checking if your nsenter version supports them or not.
>
> Then what you want is --ignore-namespaces-if-not-supported-in-kernel.
> That is a somewhat different problem than --all.
No, I also want it to do
--include-namespaces-i-did-not-know-when-writing-this-shell-script :)
>> It's better to have --all to enter all namespaces that nsenter supports.
>> If you want to, it could print a warning when using --all and nsenter
>> knows about more namespaces than the kernel or if it detects that the
>> kernel knows about more namespaces than itself.
>> But having a --all to enter “as namespaces as possible” would be the
>> right thing IMHO.
>
> The argument for --all and this is an argument that only applies to
> nsenter and not unshare is that usually things are more likely to do
> what you expect if you share more namespaces with them.
>
> The counter argument is that sharing fewer namespaces than expected
> can easily invalidate your testing and introduce subtle bugs.
>
> "nsenter -t $pid --all" is what I want most days, but I can't
> convince myself that "nsenter -t $pid -muinpUrw" is worse (just a few
> more characters) and it has the advantage that what has worked before
> should work again.
>
> Right now --all looks like a subtle trap waiting for users. Even
> --ignore-namespaces-if-not-supported-in-kernel looks like that to
> a degree.
>
> With nsenter if we don't ignore failures when something we need is
> missing the failure is up there and in your face. If we do ignore
> failures we can easily run into cases where commands that we run
> continue to work but on the wrong namespaces, causing all kinds of
> things to fail.
>
> Think about using: "nsneter -t $pid -p /bin/kill -KILL -1" to ask a
> container to shutdown. If we were to ignore the fact you can't enter
> the pid namespace than the command would kill everything and the box
> would go down.
>
> That seems very scary. So I don't like removing namespaces silently.
It could show a "Warning: Your kernel doesn't support pid namespaces"
in stderr.
No texactly ideal in your case, but slightly better.
Another option is to add --all-available, making a hard error not having
the namespaces specified by the explicit options but
--all-available to ignore missing ones.
> Having an --all that could mean everything nsenter supports this week
> is better but you start getting shell scripts that work fine on new
> distros but fail in horrible ways on old distro's with old versions of
> nsenter. That certainly is better but still a bit of a scary prospect.
>
> Eric
The namespaces-of-the-week could be a configure option for people
running on old kernels, but I don't see much way for improvement.
next prev parent reply other threads:[~2013-01-28 20:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 6:38 [PATCH 0/5] nsenter,unshare: small usability improvements Zbigniew Jędrzejewski-Szmek
2013-01-21 6:38 ` [PATCH 1/5] nsenter: allow arguments to be specified in any order Zbigniew Jędrzejewski-Szmek
2013-01-25 14:52 ` Karel Zak
2013-01-21 6:38 ` [PATCH 2/5] nsenter: add --all meaning all namespaces and cwd and root Zbigniew Jędrzejewski-Szmek
2013-01-25 15:02 ` Karel Zak
2013-01-25 16:39 ` Zbigniew Jędrzejewski-Szmek
2013-01-25 17:44 ` Eric W. Biederman
2013-01-25 17:59 ` Zbigniew Jędrzejewski-Szmek
2013-01-27 15:45 ` Ángel González
2013-01-28 2:38 ` Eric W. Biederman
2013-01-28 20:41 ` Ángel González [this message]
2013-01-21 6:38 ` [PATCH 3/5] nsenter: respect --exec no matter where it appears Zbigniew Jędrzejewski-Szmek
2013-01-25 15:02 ` Karel Zak
2013-01-25 15:07 ` Zbigniew Jędrzejewski-Szmek
2013-01-25 15:23 ` Karel Zak
2013-01-21 6:38 ` [PATCH 4/5] nsenter: rename --exec/-e to --no-fork/-F Zbigniew Jędrzejewski-Szmek
2013-01-25 15:03 ` Karel Zak
2013-01-21 6:38 ` [PATCH 5/5] unshare: add --all meaning all namespaces Zbigniew Jędrzejewski-Szmek
2013-01-25 15:04 ` Karel Zak
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=5106E28F.7040901@zoho.com \
--to=ingenit@zoho.com \
--cc=ebiederm@xmission.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
--cc=zbyszek@in.waw.pl \
/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.