[Devel] Re: [PATCH] Masquerade sender information

Eric W. Biederman ebiederm at xmission.com
Sat Nov 3 21:12:53 PDT 2007


Cedric Le Goater <clg at fr.ibm.com> writes:

> Eric W. Biederman wrote:
>> sukadev at us.ibm.com writes:
>> 
>>> +static void masquerade_sender(struct task_struct *t, struct sigqueue *q)
>>> +{
>>> +       /*
>>> +        * If the sender does not have a pid_t in the receiver's active
>>> +        * pid namespace, set si_pid to 0 and pretend signal originated
>>> +        * from the kernel.
>>> +        */
>>> +       if (!pid_ns_equal(t)) {
>>> +               q->info.si_pid = 0;
>>> +               q->info.si_uid = 0;
>>> +               q->info.si_code = SI_KERNEL;
>>> +       }
>>> +}
>> 
>> It looks like we are hooked in the right place.  However the way we
>> are handling this appears wrong.
>> 
>> First.  If we have an si_code that does not use si_pid then we should
>> not be changing si_pid, because the structure is a union and that field
>> is not always a pid value.
>> 
>> 
>> My gut feel says the code should be something like:
>> 
>> switch (q->info->si_code & __SI_MASK) {
>> case __SI_KILL:
>> case __SI_CHILD:
>> case __SI_RT:
>> case __MESQ:
>>        q->info->si_pid = task_pid_nr_ns(current, t->nsproxy->pid_ns);
>>        break;
>> }
>
> IMHO, it should be 
>
> 	q->info->si_pid = 0.
>
> we're trying to cover the case where the sender does not have a pid_t in 
> the receiver's active pid namespace.

Yes.  However you are currently missing the case where the target pid
namespace is a parent pid namespace.  So besides applying the change
to liberally we also missed the case when sending to a parent pid
namespace.  task_tgid_nr_ns(current, t->nsporxy->pid_ns) handles that.

Technically I think that is safe right now, but I think I would like
to pass in the task_struct of the sender because we have a few odd
instances where current is not the sender although every case I have
traced we do continue to be in the same process group.

Eric
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list