Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934241AbbDXTkl (ORCPT ); Fri, 24 Apr 2015 15:40:41 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:53450 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933502AbbDXTkj (ORCPT ); Fri, 24 Apr 2015 15:40:39 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Richard Guy Briggs Cc: containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, pmoore@redhat.com, linux-audit@redhat.com, eparis@parisplace.org, sgrubb@redhat.com, zohar@linux.vnet.ibm.com References: <87vbgqw163.fsf@x220.int.ebiederm.org> <20150423030751.GA6712@madcap2.tricolour.ca> <20150423204429.GA25794@madcap2.tricolour.ca> Date: Fri, 24 Apr 2015 14:36:16 -0500 In-Reply-To: <20150423204429.GA25794@madcap2.tricolour.ca> (Richard Guy Briggs's message of "Thu, 23 Apr 2015 16:44:29 -0400") Message-ID: <87bnid9v4f.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+SU92+li7YcMy5+ABwknegK26x3c3ftqA= X-SA-Exim-Connect-IP: 67.3.205.90 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 * 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 * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMDrugObfuBody_08 obfuscated drug references * 0.2 T_XMDrugObfuBody_14 obfuscated drug references X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Richard Guy Briggs X-Spam-Relay-Country: X-Spam-Timing: total 770 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 6 (0.8%), b_tie_ro: 4.9 (0.6%), parse: 1.38 (0.2%), extract_message_metadata: 6 (0.8%), get_uri_detail_list: 3.6 (0.5%), tests_pri_-1000: 4.1 (0.5%), tests_pri_-950: 1.43 (0.2%), tests_pri_-900: 1.10 (0.1%), tests_pri_-400: 43 (5.6%), check_bayes: 42 (5.4%), b_tokenize: 11 (1.4%), b_tok_get_all: 13 (1.6%), b_comp_prob: 3.5 (0.5%), b_tok_touch_all: 9 (1.1%), b_finish: 2.4 (0.3%), tests_pri_0: 690 (89.6%), tests_pri_500: 5 (0.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH V6 00/10] namespaces: log namespaces per task X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -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 Content-Length: 6260 Lines: 146 Richard Guy Briggs writes: > On 15/04/22, Richard Guy Briggs wrote: >> On 15/04/20, Eric W. Biederman wrote: >> > Richard Guy Briggs writes: >> > >> > > The purpose is to track namespace instances in use by logged processes from the >> > > perspective of init_*_ns by logging the namespace IDs (device ID and namespace >> > > inode - offset). >> > >> > In broad strokes the user interface appears correct. >> > >> > Things that I see that concern me: >> > >> > - After Als most recent changes these inodes no longer live in the proc >> > superblock so the device number reported in these patches is >> > incorrect. >> >> Ok, found the patchset you're talking about: >> 3d3d35b kill proc_ns completely >> e149ed2 take the targets of /proc/*/ns/* symlinks to separate fs >> f77c801 bury struct proc_ns in fs/proc >> 33c4294 copy address of proc_ns_ops into ns_common >> 6344c43 new helpers: ns_alloc_inum/ns_free_inum >> 6496452 make proc_ns_operations work with struct ns_common * instead of void * >> 3c04118 switch the rest of proc_ns_operations to working with &...->ns >> ff24870 netns: switch ->get()/->put()/->install()/->inum() to working with &net->ns >> 58be2825 make mntns ->get()/->put()/->install()/->inum() work with &mnt_ns->ns >> 435d5f4 common object embedded into various struct ....ns >> >> Ok, I've got some minor jigging to do to get inum too... > > Do I even need to report the device number anymore since I am concluding > s_dev is never set (or always zero) in the nsfs filesystem by > mount_pseudo() and isn't even mountable? We still need the dev. We do have a device number get_anon_bdev fills it in. > In fact, I never needed to > report the device since proc ida/idr and inodes are kernel-global and > namespace-oblivious. This is the bit I really want to keep to be forward looking. If we every need to preserve the inode numbers across a migration we could have different super blocks with different inode numbers for the same namespace. >> > - I am nervous about audit logs being flooded with users creating lots >> > of namespaces. But that is more your lookout than mine. >> >> There was a thought to create a filter to en/disable this logging... >> It is an auxiliary record to syscalls, so they can be ignored by userspace tools. >> >> > - unshare is not logging when it creates new namespaces. >> >> They are all covered: >> sys_unshare > unshare_userns > create_user_ns >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_mnt_ns >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_utsname > clone_uts_ns >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_ipcs > get_ipc_ns >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_pid_ns > create_pid_namespace >> sys_unshare > unshare_nsproxy_namespaces > create_new_namespaces > copy_net_ns Then why the special change to fork? That was not reflected on the unshare path as far as I could see. >> > As small numbers are nice and these inodes all live in their own >> > superblock now we should be able to remove the games with >> > PROC_DYNAMIC_FIRST and just use small numbers for these inodes >> > everywhere. >> >> That is compelling if I can untangle the proc inode allocation code from the >> ida/idr. Should be as easy as defining a new ns_alloc_inum (and ns_free_inum) >> to use instead of proc_alloc_inum with its own ns_inum_ida and ns_inum_lock, >> then defining a NS_DYNAMIC_FIRST and defining NS_{IPC,UTS,USER,PID}_INIT_INO in >> the place of the existing PROC_*_INIT_INO. Something like that. Just a new ida/idr allocator specific to that superblock. Yeah. It is somewhere on my todo, but I have been prioritizing getting the bugs that look potentially expoloitable fixed in the mount namespace. Al made things nice for one case but left a mess for a bunch of others. >> > I honestly don't know how much we are going to care about namespace ids >> > during migration. So far this is not a problem that has come up. >> >> Not for CRIU, but it will be an issue for a container auditor that aggregates >> information from individually auditted hosts. >> >> > I don't think migration becomes a practical concern (other than >> > interface wise) until achieve a non-init namespace auditd. The easy way >> > to handle migration would be to log a setns of every process from their >> > old namespaces to their new namespaces. As you appear to have a setns >> > event defined. >> >> Again, this would be taken care of by a layer above that is container-aware >> across multiple hosts. >> > How to handle the more general case beyond audit remains unclear. I >> > think it will be a little while yet before we start dealing with >> > migrating applications that care. When we do we will either need to >> > generate some kind of hot-plug event that userspace can respond to and >> > discover all of the appropriate file-system nodes have changed, or we >> > will need to build a mechanism in the kernel to preserve these numbers. >> >> I don't expect to need to preserve these numbers. The higher layer application >> will be able to do that translation. We need to be very aware of what is happening. The situation I am concerned about looks something like. Program A: fd1 = open(/proc/self/ns/net); fstat(fd1, &stat1) ... later ... fd2 = open(/var/run/netns/johnny); fstat(fd2, &stat2); if ((stat1.st_dev == stat2.st_dev) && (stat1.st_ino == stat2.st_ino)) { /* Same netns do something... */ } What happens when we migrate Program A with it's cached stat data of of a network namespace file? This requires either a hotplug event that Program A listens to or that the inode number and device number are preserved across migration. Exactly what we do depends on where we are when it comes up. But this is not something some layer about the program can abstract it all out so we don't need to worry about it. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/