[CRIU] [PATCH v3 06/26] files: Allow to receive further fds
Kirill Tkhai
ktkhai at virtuozzo.com
Tue Dec 6 10:11:30 PST 2016
On 06.12.2016 21:13, Pavel Emelyanov wrote:
> On 12/06/2016 08:19 PM, Kirill Tkhai wrote:
>>
>>
>> On 06.12.2016 20:16, Pavel Emelyanov wrote:
>>>
>>>> int recv_fd_from_peer(struct fdinfo_list_entry *fle)
>>>> {
>>>> struct fdinfo_list_entry *tmp;
>>>> int fd, ret;
>>>>
>>>> + if (fle->received)
>>>> + return fle->fe->fd;
>>>> +again:
>>>> ret = recv_fds(fle->fe->fd, &fd, 1, (void *)&tmp, sizeof(struct fdinfo_list_entry *));
>>>> if (ret)
>>>> return -1;
>>>>
>>>> if (tmp != fle) {
>>>> - pr_err("Received wrong fle\n");
>>>> - return -1;
>>>> + pr_info("Further fle=%p, pid=%d\n", tmp, fle->pid);
>>>> + if (!task_fle(current, fle)) {
>>>
>>> OK, so this routine makes sure the fle received sits in current's list.
>>> Two questions: 1. should we consider receiving of non-current fle as BUG()?
>>
>> Yes, it's a BUG. We fail restore if so.
>
> OK, so I'll change this return -1 to BUG() instead.
>
>>> and 2. can we make the same check by comparing fle->pid with current? All
>>> fle's are in shmem, so contents is accessible by everyone.
>>
>> It seems to be worse, because if there is a problem with fle, it may point
>> to a random memory. So fle->pid dereference will finish with SIGSEGV.
>
> But it can point to a random memory only if someone sends in this descriptor
> anything, but fle, right? All fle-s are accessible by anyone.
If we do not consider the case with malefactor, then it's only fle, yes.
More information about the CRIU
mailing list