[CRIU] [GSoC] Anonymise image files

Pavel Emelianov xemul at virtuozzo.com
Mon Apr 1 17:32:00 MSK 2019


On 3/31/19 3:10 PM, Nikhil Ramakrishnan wrote:
> Hi,
> 
> Thanks for the information! Some follow-up questions:
> 
>> When we ask for images we expect them in criu native format, not decoded json. Also, note,
>> that this feature is not only in patching the contents of the image files. The 2nd important
>> part of the task is teaching criu restore accept the anonymized images and restoring the
>> process tree up to the "ready to resume" state.
> 
> How can the process be brought back to the "ready to resume" state if
> data of memory contents, paths and registers have been shred. Will
> this involve some kind of reconstruction?

No, you just "restore" everything as if the data was OK, but at the very last moment do
not tell the process to continue execution, but ... either stop it (if --restore-stopped
is given) or exit saying smth like "cannot resume the process as no code/data exists in it"

>> The exact command to do is not decided yet. I'd see it as 'crit anon -d directory/'
> 
> So this will ideally create an anonymised copy of all the '.img' files
> (in another directory, maybe)?

Yes, I think that creating another directory and putting anonymized stuff there is what
would be the expected behavior.

> Also, are all generated image files shared, or is it only a subset
> that is required to debug?

We need all of them, of course.

>> Yes, the full path should become "random", but (!) human readable. I.e. smth like /etc/my_app.conf is expected
>> to be turned into /etc/file_1 rather than /ad324bcf098098a/f2934e123d123abd23 or alike :)
> 
> Your human-readable example retains the '/etc' part though :-)

Yes, but what'd be the point in fixing the standard paths? :)

>> Welcome, Nikhil, glad to see you interested in criu! Since you're an experienced GSoC-er you know
>> how the org part works and introduction in this area is not required.
> 
> One org-specific question comes to mind: Should the draft proposal be
> sent on the mailing list, or privately to the potential mentor(s)
> only?

It's up to you. The way I see it -- all the proposals get on the project page and we'll see them
anyway. So if you need our help in polishing the text before submitting -- feel free to drop it
to ML or to the mentor.

-- Pavel



More information about the CRIU mailing list