[CRIU] [PATCH 2/2] crit: Anonymize file paths in files.img

[Pavel Emelianov]

On 8/26/19 8:38 PM, Harshavardhan Unnibhavi wrote:
> Hi Pavel,
> 
> On Wed, Aug 14, 2019 at 3:17 PM Pavel Emelianov <xemul at virtuozzo.com> wrote:
>>
>> On 8/11/19 12:30 PM, Harshavardhan Unnibhavi wrote:
>>> Hi Pavel,
>>>
>>> Sorry for the late reply. When we restore the anonymized images(with
>>> file names anonymized) it fails to restore the task as the files
>>> themselves don't exist. I have gone through the  criu/pie/restorer.c's
>>> restore_task() function and have found that lines between 1553 and
>>> 1599 access the file descriptor from the VMA entry struct.
>>
>> Of course. The "anonymized" file paths cannot be opened, so you should patch
>> the criu restore code to make it pretend that the file in question is opened,
>> but restore some fake file descriptor instead. And abort the restore at the
>> very end.
>>
>>> I have also traced out the file access steps followed by restore from
>>> criu/cr-restore.c to criu/files-reg.c. I think the solution would be
>>> to create a new file with the anonymized name? Where should I insert
>>> this piece of code,to create a new file if it doesn't exist?
>>
>> Not create the file with anonymous name, but rather report back a fake file
>> descriptor. I'd introduce a "--anon" CLI option to the restore action for this.
> I think I will create a patch which would include the following:
> 1) --anon option,

OK

> 2)abort the restore task just before the call to
> fork_with_pid(cr_restore_tasks()
>  calls restore_root_task which calls fork_with_pid). This seems to be
> the endpoint before
> everything is read in.

Nope, that's too early. We must be sure that all the criu restore code runs OK.
You should instead make the CR_STATE_COMPLETE stage fail on the --anon option.

> Question: Will the bugs that are reported be reproduced from the
> logs(restore.log)?

I don't get the question, would you elaborate one?

-- Pavel