Re: [RFC][PATCH 2/6] sysvmsg: containerize

From: Eric W. Biederman
Date: Sun Mar 19 2006 - 10:35:00 EST


Chris Wright <chrisw@xxxxxxxxxxxx> writes:

> * Dave Hansen (haveblue@xxxxxxxxxx) wrote:
>> On Mon, 2006-03-06 at 17:57 -0800, Chris Wright wrote:
>> > * Dave Hansen (haveblue@xxxxxxxxxx) wrote:
>> > > -void __init msg_init (void)
>> > > +void __init msg_init (struct ipc_msg_context *context)
>> > > {
>> > > - ipc_init_ids(&msg_ids,msg_ctlmni);
>> > > + ipc_init_ids(&context->ids,msg_ctlmni);
>> > > ipc_init_proc_interface("sysvipc/msg",
>> > > " key msqid perms cbytes qnum lspid lrpid uid gid cuid cgid stime rtime
> ctime\n",
>> > > - &msg_ids,
>> > > + &context->ids,
>> > > sysvipc_msg_proc_show);
>> >
>> > Does that mean /proc interface only gets init_task context?
>> > Along those lines, I think now ipcs -a is incomplete from admin
>> > perspective. Suppose that's a feature from the container/vserver
>> > POV.
>>
>> It will get context from the current task, which means the current
>> container. We haven't quite decided how these things will be (or if
>> they need to be) aggregated on a a system-wide basis.
>
> 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.

> 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.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/