All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: YAMAMOTO Takashi <yamamoto@midokura.com>
Cc: Laurent Vivier <laurent@vivier.eu>, qemu-devel@nongnu.org
Subject: Re: [PATCH 2/5] linux-uesr: make exec_path realpath
Date: Mon, 24 May 2021 11:55:41 +0100	[thread overview]
Message-ID: <87r1hw4cuk.fsf@linaro.org> (raw)
In-Reply-To: <20210524045412.15152-3-yamamoto@midokura.com>


YAMAMOTO Takashi <yamamoto@midokura.com> writes:

> Otherwise, it can be easily fooled by the user app using chdir().
>
> Signed-off-by: YAMAMOTO Takashi <yamamoto@midokura.com>
> ---
>  linux-user/main.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 4dfc47ad3b..1f9f4e3820 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -55,6 +55,7 @@
>  #endif
>  
>  char *exec_path;
> +char exec_path_store[PATH_MAX];

Is there any point in keeping this as a static path rather than just
allocating it off the heap?

>  
>  int singlestep;
>  static const char *argv0;
> @@ -610,7 +611,10 @@ static int parse_args(int argc, char **argv)
>          exit(EXIT_FAILURE);
>      }
>  
> -    exec_path = argv[optind];
> +    exec_path = realpath(argv[optind], exec_path_store);
> +    if (exec_path == NULL) {
> +        exec_path = argv[optind];
> +    }

  exec_path = realpath(argv[optind], NULL)
  exec_path = exec_path ? exec_path : argv[optind];

what situations would we expect realpath to fail and in those cases is
sticking to argv[optind] safe?

>  
>      return optind;
>  }


-- 
Alex Bennée


  reply	other threads:[~2021-05-24 11:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24  4:54 [PATCH 0/5] linux-user changes to run docker YAMAMOTO Takashi
2021-05-24  4:54 ` [PATCH 1/5] linux-user: handle /proc/self/exe for execve YAMAMOTO Takashi
2021-05-24 10:50   ` Alex Bennée
2021-05-24 22:54     ` Takashi Yamamoto
2021-05-24  4:54 ` [PATCH 2/5] linux-uesr: make exec_path realpath YAMAMOTO Takashi
2021-05-24 10:55   ` Alex Bennée [this message]
2021-05-24 22:59     ` Takashi Yamamoto
2021-05-26  1:42       ` Takashi Yamamoto
2021-05-24  4:54 ` [PATCH 3/5] linux-user: Fix the execfd case of /proc/self/exe open YAMAMOTO Takashi
2021-05-24  4:54 ` [PATCH 4/5] linux-user: dup the execfd on start up YAMAMOTO Takashi
2021-05-24  4:54 ` [PATCH 5/5] linux-user: Implement pivot_root YAMAMOTO Takashi
2021-05-25 20:21   ` Laurent Vivier
2021-05-26  0:50     ` Takashi Yamamoto
2021-05-24 17:45 ` [PATCH 0/5] linux-user changes to run docker Alex Bennée
2021-05-24 23:22   ` Takashi Yamamoto
2021-05-27  1:44     ` Takashi Yamamoto
2021-05-27 13:08       ` Alex Bennée
2021-05-31  2:45         ` Takashi Yamamoto

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=87r1hw4cuk.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=yamamoto@midokura.com \
    /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.