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

[Harshavardhan Unnibhavi]

Hi,

On Tue, Aug 27, 2019 at 3:24 PM Pavel Emelianov <xemul at virtuozzo.com> wrote:
>
> 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.
Yes, I understand why now.
>
> > Question: Will the bugs that are reported be reproduced from the
> > logs(restore.log)?
>
> I don't get the question, would you elaborate one?
It was just a misunderstanding due to my incorrect suggestion to abort
before fork_with_pid(), it is
clear now.
>
> -- Pavel

Best,
Harsha