On Mon, May 24, 2021 at 7:59 PM Alex Bennée <alex.ben...@linaro.org> wrote:
>
>
> YAMAMOTO Takashi <yamam...@midokura.com> writes:
>
> > Otherwise, it can be easily fooled by the user app using chdir().
> >
> > Signed-off-by: YAMAMOTO Takashi <yamam...@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?
it's just the simplest given the api of realpath().
do you mean it's better to use malloc? why?
>
> >
> > 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?
i don't have any particular case in my mind.
i guess it rarely fails and it might be simpler to just bail out on the failure.
>
> >
> > return optind;
> > }
>
>
> --
> Alex Bennée
