All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jeff Layton <jlayton@kernel.org>
Cc: viro@zeniv.linux.org.uk, berrange@redhat.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] exec: do unshare_files after de_thread
Date: Sun, 16 Sep 2018 18:59:14 +0200	[thread overview]
Message-ID: <87tvmps7j1.fsf@xmission.com> (raw)
In-Reply-To: <20180914105310.6454-4-jlayton@kernel.org> (Jeff Layton's message of "Fri, 14 Sep 2018 06:53:10 -0400")

Jeff Layton <jlayton@kernel.org> writes:

> 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, after we've already
> killed off the other threads in the process. This helps ensure that we
> only unshare the files_struct during exec when it is truly shared with
> other processes.
>
> Note that because the unshare_files call is now done just after
> de_thread, we need a mechanism to pass the displaced files_struct back
> up to __do_execve_file. This is done via a new displaced_files field
> inside the linux_binprm.

Actually because unshare_files happens after de_thread (the point of no
return) we don't need to do anything with displaced files.  A failing
exec will clear brpm->mm, and search_binary_handler will convert any
error into force_sigsegv.

> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Reported-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/exec.c               | 11 ++++++-----
>  include/linux/binfmts.h |  1 +
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/fs/exec.c b/fs/exec.c
> index c8a68481d7eb..b4a7e659d908 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1262,6 +1262,10 @@ int flush_old_exec(struct linux_binprm * bprm)
>  	if (retval)
>  		goto out;
>  
> +	retval = unshare_files(&bprm->displaced_files);
> +	if (retval)
> +		goto out;
> +

We can place this just above do_close_on_exec.  And simply modify
unshare_files to instead of returning displaced simply put it.

We gain nothing be returning displaced_files as we are already past
the point of no return, and userspace will get an unblockable SIGSEGV
and exit.

>  	/*
>  	 * Must be called _before_ exec_mmap() as bprm->mm is
>  	 * not visibile until then. This also enables the update
> @@ -1713,7 +1717,7 @@ static int __do_execve_file(int fd, struct filename *filename,
>  {
>  	char *pathbuf = NULL;
>  	struct linux_binprm *bprm;
> -	struct files_struct *displaced;
> +	struct files_struct *displaced = NULL;
>  	int retval;
>  
>  	if (IS_ERR(filename))
> @@ -1735,10 +1739,6 @@ static int __do_execve_file(int fd, struct filename *filename,
>  	 * further execve() calls fail. */
>  	current->flags &= ~PF_NPROC_EXCEEDED;
>  
> -	retval = unshare_files(&displaced);
> -	if (retval)
> -		goto out_ret;
> -
>  	retval = -ENOMEM;
>  	bprm = kzalloc(sizeof(*bprm), GFP_KERNEL);
>  	if (!bprm)
> @@ -1817,6 +1817,7 @@ static int __do_execve_file(int fd, struct filename *filename,
>  	would_dump(bprm, bprm->file);
>  
>  	retval = exec_binprm(bprm);
> +	displaced = bprm->displaced_files;
>  	if (retval < 0)
>  		goto out;
>  
> diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
> index c05f24fac4f6..d7ec384bb1b0 100644
> --- a/include/linux/binfmts.h
> +++ b/include/linux/binfmts.h
> @@ -49,6 +49,7 @@ struct linux_binprm {
>  	unsigned int taso:1;
>  #endif
>  	unsigned int recursion_depth; /* only for search_binary_handler() */
> +	struct files_struct * displaced_files;
>  	struct file * file;
>  	struct cred *cred;	/* new credentials */
>  	int unsafe;		/* how unsafe this exec is (mask of LSM_UNSAFE_*) */

  parent reply	other threads:[~2018-09-16 22:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14 10:53 [PATCH v3 0/3] exec: fix passing of file locks across execve in multithreaded processes Jeff Layton
2018-09-14 10:53 ` [PATCH v3 1/3] exec: separate thread_count for files_struct Jeff Layton
2018-09-15 16:04   ` Oleg Nesterov
2018-09-16 16:10     ` Eric W. Biederman
2018-09-17 15:24       ` Oleg Nesterov
2018-09-17 20:45         ` Eric W. Biederman
2018-09-14 10:53 ` [PATCH v3 2/3] exec: delay clone(CLONE_FILES) if task associated with current files_struct is exec'ing Jeff Layton
2018-09-14 10:53 ` [PATCH v3 3/3] exec: do unshare_files after de_thread Jeff Layton
2018-09-15 16:37   ` Oleg Nesterov
2018-09-16 16:49     ` Eric W. Biederman
2018-09-17 15:28       ` Oleg Nesterov
2018-09-16 16:59   ` Eric W. Biederman [this message]
2018-09-16 17:38 ` [RFC][PATCH 0/3] exec: Moving unshare_files_struct Eric W. Biederman
2018-09-16 17:39   ` [RFC][PATCH 1/3] exec: Move unshare_files down to avoid locks being dropped on exec Eric W. Biederman
2018-09-17 15:49     ` Oleg Nesterov
2018-09-16 17:40   ` [RFC][PATCH 2/3] exec: Simplify unshare_files Eric W. Biederman
2018-09-17 16:23     ` Oleg Nesterov
2018-09-17 20:26       ` Eric W. Biederman
2018-09-16 17:41   ` [RFC][PATCH 3/3] exec: Remove reset_files_struct Eric W. Biederman
2018-09-17 15:59   ` [RFC][PATCH 0/3] exec: Moving unshare_files_struct Oleg Nesterov
2018-09-18 22:18     ` Eric W. Biederman
2018-09-17 16:24   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tvmps7j1.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=berrange@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.