All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Meredydd Luff <meredydd@senatehouse.org>
Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH signal#execve2] syscalls,x86: Add execveat() system call (v3)
Date: Sun, 6 Jan 2013 16:31:00 +0000	[thread overview]
Message-ID: <20130106163100.GI4939@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20120912011654.GQ13973@ZenIV.linux.org.uk>

OK, now that sys_execve() unification has settled down, let's get back
to this one.  The real problem is what you are doing with bprm->filename
and bprm->interp; blind use of ->d_name is completely wrong.

For what it's worth, how should it work for e.g. shell scripts?  That's
the main user of bprm->{filename,interp}, after all - other places are
either seriously exotic or are just using it for printks.

For shell scripts, however, these guys are really used - we have the original
argv[0] removed and <shell name> <optional argument> <filename> pushed in
its place.

How will it work with execveat()?  If we have procfs in place, we can
cook an equivalent pathname (/proc/self/fd/<n>/<relative part of pathname>),
but then why not do just that in userland and be done with that?

  reply	other threads:[~2013-01-06 16:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12  0:55 [PATCH signal#execve2] syscalls,x86: Add execveat() system call (v3) Meredydd Luff
2012-09-12  1:16 ` Al Viro
2013-01-06 16:31   ` Al Viro [this message]
2013-01-08 12:39     ` Meredydd Luff
2014-04-22 11:47       ` David Drysdale

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=20130106163100.GI4939@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=meredydd@senatehouse.org \
    --cc=mingo@redhat.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.