![]() | |||||||||||||
Messages in this thread |
* 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). > > 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. thanks, -chris - 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/ | ||||||||||||
| Last update: 2006-03-20 19:37 [from the cache] ©2003-2008 | |||||||||||||