signal handling description for Michaels CLONE_NEWPID man page

[Nadia . Derbey]

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
+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).
+
+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

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