Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751939AbcJJUqL (ORCPT ); Mon, 10 Oct 2016 16:46:11 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:47241 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbcJJUqJ (ORCPT ); Mon, 10 Oct 2016 16:46:09 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andrei Vagin Cc: , , , Serge Hallyn , Kees Cook References: <1471291822-539-1-git-send-email-avagin@openvz.org> <20161006175146.GA25935@outlook.office365.com> <87wphlclwe.fsf@x220.int.ebiederm.org> <20161010162202.GA31628@outlook.office365.com> Date: Mon, 10 Oct 2016 15:44:09 -0500 In-Reply-To: <20161010162202.GA31628@outlook.office365.com> (Andrei Vagin's message of "Mon, 10 Oct 2016 09:22:03 -0700") Message-ID: <871szo53za.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=1bthSZ-0006XS-Eu;;;mid=<871szo53za.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=75.170.125.99;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19AhbaQ4vFQDbrCrbwrigkJIjGFpcEvD1o= X-SA-Exim-Connect-IP: 75.170.125.99 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.7 XMSubLong Long Subject * 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Andrei Vagin X-Spam-Relay-Country: X-Spam-Timing: total 247 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.8 (1.5%), b_tie_ro: 2.8 (1.1%), parse: 0.77 (0.3%), extract_message_metadata: 11 (4.3%), get_uri_detail_list: 1.42 (0.6%), tests_pri_-1000: 6 (2.3%), tests_pri_-950: 1.18 (0.5%), tests_pri_-900: 0.96 (0.4%), tests_pri_-400: 22 (8.9%), check_bayes: 21 (8.5%), b_tokenize: 7 (2.7%), b_tok_get_all: 7 (2.8%), b_comp_prob: 2.2 (0.9%), b_tok_touch_all: 2.8 (1.2%), b_finish: 0.76 (0.3%), tests_pri_0: 196 (79.2%), check_dkim_signature: 0.49 (0.2%), check_dkim_adsp: 3.1 (1.3%), tests_pri_500: 3.7 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/2 v2] userns: show current values of user namespace counters 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 in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2031 Lines: 48 Andrei Vagin writes: > On Thu, Oct 06, 2016 at 02:33:53PM -0500, Eric W. Biederman wrote: >> Andrei Vagin writes: >> >> > Hello Eric, >> > >> > What do you think about this series? It should be useful to know current >> > usage for user counters. >> >> I am in favor of knowing the values. Unless there is a good reason not >> to we should export the values with a read-only sysctl. I believe that >> is what other similar limits do. > > I want to have a place where I will be able to get limits for all > users. I can't imagine how to do this with a sysctl. It will looks like > multiline sysct-s, what doesn't look good. I will think. If you will > have any ideas let me know. Thanks. Something that has been on my wish list for a while has been to modify /proc/sys/... to also show up under /proc//sys/... for the non-global values. Now it might make sense to show these things in an alternate filesystem. At the same time I am a little leary of the desire. Changing these limits and watching them in a per-process / per-user sense is fine. However their fundamental purpose is to be set and forget limits and that only rarely should anyone need to mess with. Which makes the primary purpose of looking at them debugging and verifying that the limits are set to reasonable values. Active management if someone wants to go there is possible but it will never be the primary purpose of these limits. >> As for having per process knowledge I think that is probably something >> we want to solve for these sysctls as well. >> >> I don't think I saw anyone looking at this code from the perspective of >> information leaks. I think we need to ask that question, as similar >> interfaces have been problematic from an information leak point of view. > > It's a good question. I expect that we don't actually care. The kernel tends to leak a lot of this kind of information. But I figure we should at least be able to say we thought about it and we don't care. Eric