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: <20110817130531.GA12204@redhat.com>
Date:	Wed, 17 Aug 2011 15:05:31 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	akpm@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, lennart@...ttering.net,
	kay.sievers@...y.org, linux-man@...r.kernel.org,
	roland@...k.frob.com, torvalds@...ux-foundation.org
Subject: Re: +
	prctl-add-pr_setget_child_reaper-to-allow-simple-process-supervision
	.patch added to -mm tree

On 08/17, Oleg Nesterov wrote:
>
> On 08/16, Andrew Morton wrote:
> >
> > From: Lennart Poettering <lennart@...ttering.net>
> >
> > Userspace service managers/supervisors need to track their started
> > services.  Many services daemonize by double-forking and get implicitely
> > re-parented to PID 1.  The process manager will no longer be able to
> > receive the SIGCHLD signals for them.
> >
> > With this prctl, a service manager can mark itself as a sort of 'sub-init'
> > process, able to stay as the parent process for all processes created by
> > the started services.  All SIGCHLD signals will be delivered to the
> > service manager.
>
> I try to never argue with the new features. But to be honest, this
> doesn't look very good to me.
>
> OK, a service manager M does prctl(PR_SET_CHILD_REAPER), then it forks
> a service X which forks another child C and exits. Then C exits and
> notifies M.
>
> But. How can M know that the service X should be restarted? It only
> knows the pid. What if wait(WEXITED) succeeds because C in turn does
> fork + exit? What M has 2 or more services?

Also. I am almost sure I have already reviewed a very similar patch
a long ago. Ungortunately, I can't find the previous discussion, and
I can't recall why that patch was not accepted.

But, I seem to remember, that patch cleared ->child_reaper on exec,
I think this makes sense.

And I am not sure about security. No, I do not see any problems, just
I don't know. Say, should we check the creds during reparenting? I
dunno.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ