linux-kernel - Re: Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?

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]

Message-Id: <DA877BA4-5DCC-4F72-A6D5-B08ABEF1672B@ci.uchicago.edu>
Date:	Fri, 30 Mar 2012 08:26:44 -0500
From:	Karl Pickett <kjp@...uchicago.edu>
To:	Karl Pickett <kjp@...uchicago.edu>
Cc:	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	kay.sievers@...y.org, Lennart Poettering <lennart@...ttering.net>
Subject: Re: Is prctl(PR_SET_CHILD_SUBREAPER) going to break my code which checks getppid == 1?


On Mar 30, 2012, at 8:17 AM, Karl Pickett wrote:

> On Mar 30, 2012, at 7:44 AM, Oleg Nesterov wrote:
> 
>> On 03/29, Karl Pickett wrote:
>>> 
>>> Re: http://thread.gmane.org/gmane.linux.kernel/1236479
>>> 
>>> I'm wondering if this is going to break code that checks getppid() == 1?
>>> 
>>> I have a TCL/TK GUI app that spawns ssh.  I want the ssh to die
>>> immediately if the GUI process crashes, so ssh is launched with a wrapper
>>> c program that does:
>>> 
>>>  prctl(PR_SET_PDEATHSIG, SIGHUP);
>>>  if (getppid() == 1) /* parent died already? */
>>>      return 0;
>> 
>> Yes, this won't work if the parent of this app does PR_SET_CHILD_SUBREAPER.
>> 
>>> So what is getppid() going to return for some user using this new
>>> 'session manager reaper'?
>> 
>> The new parent's pid ;)
>> 
>> Perhaps you can do something like
>> 
>> 	ppid_for_child = getpid();
>> 
>> 	if (!fork()) {
>> 		// Child
>> 		prctl(PR_SET_PDEATHSIG);
>> 		if (getppid() != ppid_for_child)
>> 			return;
>> 		...
>> 	}
> 
> There are two problems with that.  1., I don't think TCL/TK lets me access the parent pre-fork env like that - all I can change is the execed code.  2., That has a clear race with pid wrap around.  You really need a prctl(PR_DID_MY_REAL_PARENT_DIE) function to be safe.

Maybe there is not a race with pid wrap around since that can not create a 'new' parent for me?  Too early in the morning.  

1 init -> 2 Subreaper -> 3 Gui App -> 4 ssh.  If 3 (gui app dies), is there any way another process with pid 3 could become my parent?   

Maybe with TCL/TK I could set an environment variable that records its pid.  I already thought about this, but for some reason was still thinking pid wrap around would happen.  However, that requires access to that programs source code (which I fortunately have) but I think the authors of the patch need to recognize the compatibility problems of this patch and provide a better workaround (like PR_DID_MY_REAL_PARENT_DIE).  Otherwise, PR_SET_PDEATHSIG is not as useful as it has been for quite some time.

> 
> 
>> 
>> Just in case, I do not know how PR_SET_CHILD_SUBREAPER will be really used.
>> I do not know if systemd will run the "normal" user applications under
>> PR_SET_CHILD_SUBREAPER. Probably yes, but this is the question to Kay.
>> 
>> Oleg.
>> 
> 

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