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

[Eric W. Biederman]

Chris Wright <chrisw@xxxxxxxxxxxx> writes:

> * Eric W. Biederman (ebiederm@xxxxxxxxxxxx) wrote:
>> Chris Wright <chrisw@xxxxxxxxxxxx> 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
-
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/