Re: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns boundary

[Roland McGrath]

> It is especially useful, and this is a deliberate feature.  

Ok, I thought that might be so.

> In practice I don't care about si_pid and I doubt I care about processes
> sending signals outside of their pid namespace.  But I do care about
> sharing a tty and a session and having job control work.

Understood.

> >> pid 10 should see si_pid 12.
> >> pid 11 should see si_pid 2.
> >
> > We indeed have this problem if we think it's useful to continue to have
> > a concept of pgrp for the sub-init that can see outside its own NS.
> >
> >> Neither should see si_pid 0, as from_ancestor_ns will not be true.
> >
> > Perhaps replace from_ancestor_ns with struct pid_namespace *sender_ns?
> > (I don't know if there was already a can of worms with such an idea before.)
> > Then si_pid could be translated as appropriate for each recipient.
> > (Or perhaps just struct pid *sender and reset si_pid from that.)
> 
> The last was my original line of thinking.  I seem to recall Oleg
> figuring the code gets pretty ugly when you add in the necessary test
> to see if si_pid is actually present.

Well, the existing test to set from_ancestor_ns is in one place and we
think that its logic is OK.  What I had in mind was that when that logic
says "0", we pass NULL and the innards don't touch .si_pid (same as now);
when it says "1", we pass a pointer and the innards do rewrite it.

> There are several other cases where we also signal a process outside
> of our current pid namespace, where we have a pid inside the recipients
> pid namespace.  do_notify_parent is the easiest example.

It's the only example that Oleg has mentioned.  What others are there?

> a) We pass in struct pid *sender and we reset si_pid in send_signal.
> b) We make the rule that send_signal must receive a valid siginfo from
>    the caller and we only do the extra work for process groups.

That's what I said. ;-) The a) option seems cleaner to me regardless, to
the extent that the "from_ancestor_ns" approach is a "clean" one.  But I
think it would be best to fully elucidate what we think about desireable
semantics for the whole spectrum of cross-NS signal-sending cases before
actually choosing the implementation details.


Thanks,
Roland
--
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/