On Fri, 2008-11-28 at 16:58 -0500, Michael Kerrisk wrote: > Hi Nadia, > > Thanks for putting this together. A few questions below. > > On Thu, Nov 27, 2008 at 2:07 AM, <Nadia.Derbey@xxxxxxxx> wrote: > > Michael, > > > > Here is the proposal for a description of signals handling in pid > > namespaces. > > > > This applies on top of your CLONE_NEWPID patch. > > > > Regards, > > Nadia > > > > --- > > man2/clone.2 | 23 +++++++++++++++++++++++ > > 1 file changed, 23 insertions(+) > > > > Index: man-pages-3.13/man2/clone.2 > > =================================================================== > > --- man-pages-3.13.orig/man2/clone.2 2008-11-24 09:34:30.000000000 +0100 > > +++ man-pages-3.13/man2/clone.2 2008-11-27 09:17:53.000000000 +0100 > > @@ -226,6 +226,29 @@ configuration option and requires that t > > .RB (CAP_SYS_ADMIN ). > > This flag can't be specified in conjunction with > > .BR CLONE_THREAD . > > + > > +.BR "Signals handling:" > > +just like all the system calls that address a PID, signals can only be sent > > +to a process whose PID belongs to the same namespace as the caller. > > + > > +There are ways signals can be sent across namespaces boundaries such that > > Just so I'm clear. We're talking about the case here where, for > example, a process in a parent namespace sends a signal to a process > in the child namespace. In such a case, the PID of the sender is not > meaningful. Right? Yes, a process doesn't have a valid pid number in a descendant pid namespace. So a process receiving a signal from an upper level PID namespace will see the signal originator as "not meaningful". > > > +the sender does not have a valid pid in the receiver's pid namespace. > > +In such cases, the sender pid will be seen by the receiver as a 0 value > > +(this has an impact, for example, on the > > +.BR siginfo_t > > +structure contents - NOTE, this is still under development). > > Can you fill me in on the possibilities of "this is still under development"? This is because the semantics are still under discussion (see thread http://lkml.org/lkml/2008/11/25/458). There are also places that are not addressed by this patchset, but where the signal originator pid might have to be cleared, like the following: 1. POSIX message queues: if the process that registers for notification through mq_notify() is in a descendant namespace of the one that sends a message to the mqueue. 2. a process is set as the SIGIO receiver through fcntl(F_SETOWN) and the write() to the file is done by a process that belongs to an ancestor namespace. Also, if the implementation proposed by this patchset is adopted, we should add a note on what could appear as a change in the ABI for the rt_sigqueueinfo() call: this call explicitely sends a siginfo_t structure. So the si_pid might have been filled by the caller. But if the signal receiver of this rt_sigqueueinfo() is in a descendant namespace, the si_pid field will be cleared by the kernel. Regards, Nadia > > Cheers, > > Michael > > > +The "init" process of a PID namespace has a particular status, since it > > +is known both by its children as PID 1 and by its father's PID namespace > > +as any other PID. Thus, the "init" process of a PID namespace can be sent > > +any signal by a process that belongs to its ancestor's PID namespace (given > > +that the sender has the appropriate permission). But the only signals that > > +can be sent to the "init" process of a PID namespace from its own namespace > > +are those for which it has explicitly installed signal handlers. > > +More precisely, signals are sent successfully (i.e > > +.BR kill (2) > > +will not fail), but the "init" process will silently ignore unhandled signals. > > + > > .TP > > .BR CLONE_PARENT " (since Linux 2.3.12)" > > If > > > > -- > > > > > -- Nadia Derbey <Nadia.Derbey@xxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
