Messages in this thread | | | Date | Sat, 15 Sep 2018 18:37:04 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH v3 3/3] exec: do unshare_files after de_thread |
| |
On 09/14, Jeff Layton wrote: > > POSIX mandates that open fds and their associated file locks should be > preserved across an execve. This works, unless the process is > multithreaded at the time that execve is called. > > In that case, we'll end up unsharing the files_struct but the locks will > still have their fl_owner set to the address of the old one. Eventually, > when the other threads die and the last reference to the old > files_struct is put, any POSIX locks get torn down since it looks like > a close occurred on them. > > The result is that all of your open files will be intact with none of > the locks you held before execve. The simple answer to this is "use OFD > locks", but this is a nasty surprise and it violates the spec. > > Fix this by doing unshare_files later during exec,
See my reply to 1/3... if we can forget about the races with get_files_struct() we can probably make a much simpler patch, plus we do not need 2/2, afaics.
What I really can't understand is why we need to _change_ current->files early in do_execve().
IOW. Lets ignore do_close_on_exec(), lets ignore the fact that unshare_fd() can fail and thus it makes sense to call it before point-of-no-return.
Any other reason why we can't simply call unshare_files() at the end of __do_execve_file() on success?
Oleg.
| |