linux-kernel - Re: [PATCH] Introduce ActivePid: in /proc/self/status (v2, was Vpid:)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Jun 2011 16:25:49 +0200
From:	Cedric Le Goater <clg@...ibm.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	Greg Kurz <gkurz@...ibm.com>, linux-kernel@...r.kernel.org,
	ebiederm@...ssion.com, containers@...ts.osdl.org,
	akpm@...ux-foundation.org, xemul@...nvz.org
Subject: Re: [PATCH] Introduce ActivePid: in /proc/self/status (v2, was	Vpid:)

On 06/16/2011 03:06 PM, Oleg Nesterov wrote:
> On 06/16, Cedric Le Goater wrote:
>>
>> We have a case where a task in a parent pid namespace needs to kill
>> another task in a sub pid namespace only knowing its internal pid.
>> the latter has been communicated to the parent task through a file or
>> a unix socket.
> 
> OK, thanks, this partly answers my question... But if they communicate
> anyway, it is not clear why the signal is needed.

Well, user space always finds ways to challenge the kernel.

Our case is related to HPC. The batch manager runs jobs inside lxc 
containers (using namespaces) and signals are sent to the application 
for different reasons. First, to cleanly exit but also for other more 
specific actions related to the cluster interconnects. 

>> This 'ActivePid' information in /proc is not sufficient to identity
>> the task, you also need the list of the tasks which are living in
>> the pid namespace.
> 
> Yes, I see.
> 
>> a new kill syscall could be the solution:
>>
>>     int pidns_kill(pid_t init_pid, pid_t some_pid);
>>
>> where 'init_pid' identifies the namespace and 'some_pid' identifies
>> a task in this namespace. this is very specific but why not.
> 
> Yes, I also thought about this. Should be trivial.
> 
> Or int sys_tell_me_its_pid(pid_t init_pid, pid_t some_pid).

why not. it's even better because more general.

> Just in case.... This is hack, yes, but in fact you do not need the
> kernel changes to send a signal inside the namespace. You could
> ptrace sub_init, and execute the necessary code "inside" the namespace.

hmm, I look at that.

Thanks,

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