From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751882AbcGXFNY (ORCPT ); Sun, 24 Jul 2016 01:13:24 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:45025 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751011AbcGXFNV (ORCPT ); Sun, 24 Jul 2016 01:13:21 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andrey Vagin Cc: linux-kernel@vger.kernel.org, James Bottomley , Serge Hallyn , linux-api@vger.kernel.org, containers@lists.linux-foundation.org, Alexander Viro , criu@openvz.org, linux-fsdevel@vger.kernel.org, "Michael Kerrisk \(man-pages\)" References: <1468548742-32136-1-git-send-email-avagin@openvz.org> Date: Sun, 24 Jul 2016 00:00:13 -0500 In-Reply-To: <1468548742-32136-1-git-send-email-avagin@openvz.org> (Andrey Vagin's message of "Thu, 14 Jul 2016 19:12:18 -0700") Message-ID: <87k2gbmy02.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bRBiw-0001PH-TP;;;mid=<87k2gbmy02.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX199tDRG5NhnvlxppFZpd7aePkv7fqmT8UY= 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.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 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 * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Andrey Vagin X-Spam-Relay-Country: X-Spam-Timing: total 1231 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.4 (0.4%), b_tie_ro: 3.2 (0.3%), parse: 1.20 (0.1%), extract_message_metadata: 15 (1.3%), get_uri_detail_list: 2.1 (0.2%), tests_pri_-1000: 3.9 (0.3%), tests_pri_-950: 0.91 (0.1%), tests_pri_-900: 0.75 (0.1%), tests_pri_-400: 21 (1.7%), check_bayes: 19 (1.6%), b_tokenize: 4.3 (0.4%), b_tok_get_all: 7 (0.5%), b_comp_prob: 2.4 (0.2%), b_tok_touch_all: 3.3 (0.3%), b_finish: 0.99 (0.1%), tests_pri_0: 1173 (95.4%), check_dkim_signature: 0.40 (0.0%), check_dkim_adsp: 3.8 (0.3%), tests_pri_500: 7 (0.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 1/5] namespaces: move user_ns into ns_common 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: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrey Vagin writes: > Every namespace has a pointer to an user namespace where is was created, > but they're all privately embedded in the individual namespace specific > structures. > > Now we are going to add an user-space interface to get an owning user > namespace, so it looks reasonable to move it into ns_common. > > Originally this idea was suggested by James Bottomley. I skimmed through this and I really don't like move user_ns into ns_common. If for no other reason that it seems to have guarantteed this patchset as written would not apply to my tree. > diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h > index 8297e5b..a941b44 100644 > --- a/include/linux/user_namespace.h > +++ b/include/linux/user_namespace.h > @@ -27,11 +27,15 @@ struct user_namespace { > struct uid_gid_map gid_map; > struct uid_gid_map projid_map; > atomic_t count; > - struct user_namespace *parent; > int level; > kuid_t owner; > kgid_t group; > - struct ns_common ns; > + > + /* ->ns.user_ns and ->parent are synonyms */ > + union { > + struct user_namespace *parent; > + struct ns_common ns; > + }; > unsigned long flags; > > /* Register of per-UID persistent keyrings for this namespace */ This union is unmaintainable. It is very easy for someone to change ns_common and accidentially break this. The C standard does not allow data to be accessed as either one union member or the other. Which means semantically this code relies on undefined behavior, and the compiler can do anything in this case and gcc has sometimes been known to use that allowance. Eric