mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Chris Wright <chrisw@sous-sol.org>
Cc: Dave Hansen <haveblue@us.ibm.com>,
	linux-kernel@vger.kernel.org, serue@us.ibm.com,
	frankeh@watson.ibm.com, clg@fr.ibm.com,
	Herbert Poetzl <herbert@13thfloor.at>,
	Sam Vilain <sam@vilain.net>
Subject: Re: [RFC][PATCH 2/6] sysvmsg: containerize
Date: Mon, 20 Mar 2006 14:29:01 -0700	[thread overview]
Message-ID: <m1d5ggvm8y.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060320193414.GQ15997@sorel.sous-sol.org> (Chris Wright's message of "Mon, 20 Mar 2006 11:34:14 -0800")

Chris Wright <chrisw@sous-sol.org> writes:

> * Eric W. Biederman (ebiederm@xmission.com) wrote:
>> Chris Wright <chrisw@sous-sol.org> writes:
>> > The /proc interface is registering with &context->ids of init_task.  So,
>> > all other contexts using that interface will be looking at the wrong
>> > info, AFAICT.
>> 
>> We need to make this per process in /proc to get it right.
>> So /proc/sysvipc becomes a symlink to /proc/<pid>/sysvipc.
>
> That, and any considerations for context access to protect against
> reading /proc/pid/sysvipc/* (assuming you can share pid namespace,
> while not sharing sysvipc context).

Yes.  Although reading is fairly harmless activity.

>> > As you can tell my concerns are in resource consumption.  If a user can
>> > create contexts which it can hide from sysadmin, and they aren't subject
>> > to sysadmin mandated resource limits, it's effectively a leak, esp. since
>> > these resources don't die with exit(2).
>> 
>> I haven't spotted it yet in Dave's series but this is something that should
>> happen when all of the tasks using the ipc_context in this case exit.
>
> Making it look like an 'init 0' from the P.O.V. of that ipc_context, WFM.
> Seems the context needs to have context limits so any privileged process
> in the context is still subject to the top-level administered limits.

Agreed.  Getting the limit checking correct without imposing measurable
overhead is tricky.  My gut feel is that the limits should remain global
until we can agree on how to implement more fine grained limits.


Eric

  reply	other threads:[~2006-03-20 21:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-06 23:52 [RFC][PATCH 0/6] support separate namespaces for sysv Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 1/6] prepare sysctls for containers Dave Hansen
2006-03-07  0:50   ` Herbert Poetzl
2006-03-07  2:00     ` Dave Hansen
2006-03-07  2:45       ` Herbert Poetzl
2006-03-19 15:54         ` Eric W. Biederman
2006-03-07  1:01   ` Chris Wright
2006-03-07  2:04     ` Dave Hansen
2006-03-07  2:18       ` Chris Wright
2006-03-07  3:02       ` Sam Vilain
2006-03-07  1:24   ` Al Viro
2006-03-07  1:55     ` Dave Hansen
2006-03-07  1:57       ` Al Viro
2006-03-19 14:50         ` Eric W. Biederman
2006-03-19 15:29   ` Eric W. Biederman
2006-03-06 23:52 ` [RFC][PATCH 2/6] sysvmsg: containerize Dave Hansen
2006-03-07  1:57   ` Chris Wright
2006-03-07  2:08     ` Dave Hansen
2006-03-07  2:34       ` Chris Wright
2006-03-19 15:36         ` Eric W. Biederman
2006-03-20 19:34           ` Chris Wright
2006-03-20 21:29             ` Eric W. Biederman [this message]
2006-03-20 21:50               ` Chris Wright
2006-03-06 23:52 ` [RFC][PATCH 3/6] sysvmsg: containerize sysctls Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 4/6] sysvsem: containerize Dave Hansen
2006-03-07  2:44   ` Chris Wright
2006-03-07  5:08     ` Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 5/6] sysvshm: containerize Dave Hansen
2006-03-06 23:52 ` [RFC][PATCH 6/6] sysvshm: containerize sysctls Dave Hansen

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=m1d5ggvm8y.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=chrisw@sous-sol.org \
    --cc=clg@fr.ibm.com \
    --cc=frankeh@watson.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@vilain.net \
    --cc=serue@us.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome