Cyrill Gorcunov <[email protected]> writes: > On Mon, Jul 25, 2016 at 01:21:51PM -0500, Eric W. Biederman wrote: >> Stanislav Kinsburskiy <[email protected]> writes: >> >> > Gentlemen, >> > >> > Looks like there are no objections to this patch. >> >> There has been objection. >> >> The only justification for the change that has been put forward is >> someone doing a restore lazily. I don't see a reason why you can't call >> prctl_set_mm_exe_file until you have the file in place instead of a >> place holder that sounds like a trivial solution to any restore issues. >> >> The truth is an unlimited settable exe link is essentially meaningless, >> as you can't depend on it for anything. One shot seems the best >> compromise I have seen put forward between the definite >> checkpoint/restart requirement to set the this value and the general >> need to have something that makes sense and people can depend on for >> system management. >> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't >> validate that the new file is a actually mmaped executable. We would >> definitely need that to be fixed before even considering removing the >> limit. > > Could you please elaborate? We check for inode being executable, > what else needed?
That the inode is mmaped into the process with executable mappings. Effectively what we check the old mapping for and refuse to remove the old mm_exe_file if it exists. I think a reasonable argument can be made that if the file is executable, and it is mmaped with executable pages that exe_file is not a complete lie. Which is the important part. At the end of the day how much can userspace trust /proc/pid/exe? If we are too lax it is just a random file descriptor we can not trust at all. At which point there is exactly no point in preserving it in checkpoint/restart, because nothing will trust or look at it. If the only user is checkpoint/restart perhaps it should be only ptrace that can set this and not the process itself with a prctl. I don't know. All I know is that we should work on making it a very trustable value even though in some specific instances we can set it. Eric
