Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1441823
| Path | csiph.com!feeder.erje.net!1.us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod |
|---|---|
| From | ebiederm@xmission.com (Eric W. Biederman) |
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 2/2] namespaces: add transparent user namespaces |
| Date | Wed, 13 Jul 2016 00:50:02 +0200 |
| Message-ID | <rUeF4-2Ns-17@gated-at.bofh.it> (permalink) |
| References | <rNj6O-6Ez-9@gated-at.bofh.it> <rNJDX-6O7-3@gated-at.bofh.it> <rNJDX-6O7-1@gated-at.bofh.it> <rOGE1-24t-19@gated-at.bofh.it> <rUcjU-1np-9@gated-at.bofh.it> |
| User-Agent | Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=utf-8 |
| Content-Transfer-Encoding | 8BIT |
| X-Xm-Spf | eid=1bN6Q6-0001Q0-Q7;;;mid=<87k2gqxzbd.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral |
| X-Xm-Aid | U2FsdGVkX1+2fau8LhJ0q28KxD1YPFH3Fg77y2SJA6k= |
| X-Sa-Exim-Connect-IP | 67.3.204.119 |
| X-Sa-Exim-Mail-From | ebiederm@xmission.com |
| X-Spam-Report | * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] |
| X-Spam-Dcc | XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 |
| X-Spam-Combo | ;Mickaël Salaün <mic@digikod.net> |
| X-Spam-Timing | total 963 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.9 (0.4%), b_tie_ro: 2.8 (0.3%), parse: 1.57 (0.2%), extract_message_metadata: 37 (3.8%), get_uri_detail_list: 5 (0.5%), tests_pri_-1000: 12 (1.2%), tests_pri_-950: 2.0 (0.2%), tests_pri_-900: 1.69 (0.2%), tests_pri_-400: 53 (5.5%), check_bayes: 51 (5.3%), b_tokenize: 19 (1.9%), b_tok_get_all: 16 (1.6%), b_comp_prob: 8 (0.8%), b_tok_touch_all: 3.9 (0.4%), b_finish: 0.87 (0.1%), tests_pri_0: 840 (87.2%), check_dkim_signature: 0.94 (0.1%), check_dkim_adsp: 4.6 (0.5%), tests_pri_500: 6 (0.6%), rewrite_mail: 0.00 (0.0%) |
| X-Spam-Flag | No |
| X-Sa-Exim-Version | 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) |
| X-Sa-Exim-Scanned | Yes (on in02.mta.xmission.com) |
| Sender | robomod@news.nic.it |
| List-ID | <linux-kernel.vger.kernel.org> |
| X-Mailing-List | linux-kernel@vger.kernel.org |
| Approved | robomod@news.nic.it |
| Lines | 86 |
| Organization | linux.* mail to news gateway |
| X-Original-Cc | Michael Kerrisk <mtk.manpages@gmail.com>, Kees Cook <keescook@chromium.org>, Linux Containers <containers@lists.linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, Seth Forshee <seth.forshee@canonical.com>, John Stultz <john.stultz@linaro.org>, Al Viro <viro@zeniv.linux.org.uk>, Andy Lutomirski <luto@kernel.org>, Cyrill Gorcunov <gorcunov@openvz.org>, Jann Horn <jann@thejh.net>, Christoph Lameter <cl@linux.com>, Janis Danisevskis <jdanis@google.com>, Calvin Owens <calvinowens@fb.com>, Alexey Dobriyan <adobriyan@gmail.com> |
| X-Original-Date | Tue, 12 Jul 2016 17:32:22 -0500 |
| X-Original-Message-ID | <87k2gqxzbd.fsf@x220.int.ebiederm.org> |
| X-Original-References | <CAG48ez3ELMSsWhe9X_uq_3M7TjJxq=SnAr09g72nTkCRQY008g@mail.gmail.com> <1466814210-3778-1-git-send-email-jannh@google.com> <1466814210-3778-2-git-send-email-jannh@google.com> <87mvm6y8g9.fsf@x220.int.ebiederm.org> <57854EE5.1030707@digikod.net> |
| X-Original-Sender | linux-kernel-owner@vger.kernel.org |
| Xref | csiph.com linux.kernel:1441823 |
Show key headers only | View raw
Mickaël Salaün <mic@digikod.net> writes: > Hi, > > I have been looking for this kind of feature for StemJail [1]. One of > the main idea is to being able to create mount points inside a jail as > an unprivileged user but to keep as much as possible the same > environment from outside the jail. For now, I can only create a > mapping for the current user, so when a process list any files > belonging to another user/group it get "nobody", which seems weird > from a user point of view :) Weird but I have never found it harmful. The big thrashing about with adding s_user_ns is complete in my tree so I can accept a reasonable patch, and transparent user namespaces is on the edge. If transparent user namespaces solve anything except for weird. They are simple enough that given a good quality patch I will merge them. Still I want to make certain they solve something real or else I am not certain the added complexity is worth the maintenance burden. Especially in a part of the code where getting confused and making small mistakes results in security issues. On the flip side it isn't that much weirder than from_kuid_munged today so it may not be any kind of problem at all. > > Regards, > Mickaël > > > 1. https://github.com/stemjail/stemjail > > > On 27/06/2016 17:09, Eric W. Biederman wrote: >> >> Added a few more relevant cc's. >> >> Jann Horn <jannh@google.com> writes: >> >>> This allows the admin of a user namespace to mark the namespace as >>> transparent. All other namespaces, by default, are opaque. >> >> >> I have just skimmed through this and at a high level this doesn't seem >> too scary. Having an identity mapped user namespace that just limits >> you to using a subset of uids and gids while allowing displaying the >> full range of uids and gids. >> >> I don't quite get the use case and I would like to a little better >> but in the long term this shouldn't cause any significant maintenance >> issues, so I don't have any objects. >> >> At the same time this isn't quite the time to merge this. I am in the >> process of slowly going through Seth's vfs changes to support things >> such as truly unprivileged fuse support. Those changes alter which >> places can always be assumed to be init_user_ns (many fewer), and also >> slightly change the set of from_kuid calls being made. >> >> The changes that have made it through my review currently reside at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next >> >> Those vfs changes make it conceivable and simple from an infrastructure >> standpoint to transition fileystems to unprivileged user namespace >> mounts, with perhaps as little work as just setting FS_USER_NS. At the >> same time that won't be recommend because of the difficulty verifying >> evil filesystem contents can't cause fs implementations to do bad things >> is difficult. >> >> That change means your first patch that just zaps all from_kuid_munged >> users in init_user_ns isn't a particularly good idea. I don't think it >> is a good idea to have one set of rules for things that will always be >> init_user_ns and another set of rules for code that will change. >> >> The long and short of this is I am asking you to wait a week or so and >> rebase this on my for-next branch so that we can confirm this change >> interacts nicely will all of the other on-going work. >> >> Thank you, >> Eric Biederman Eric
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH v2 2/2] namespaces: add transparent user namespaces Mickaël Salaün <mic@digikod.net> - 2016-07-12 22:20 +0200 Re: [PATCH v2 2/2] namespaces: add transparent user namespaces ebiederm@xmission.com (Eric W. Biederman) - 2016-07-13 00:50 +0200
csiph-web