From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11342 Path: news.gmane.org!.POSTED!not-for-mail From: John Regan Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question about setting argv[0] when manually using dynamic linker Date: Wed, 17 May 2017 14:16:09 -0500 Message-ID: References: <20170517070115.GL6320@example.net> <20170517162428.GH17319@brightrain.aerifal.cx> <20170517190705.GM6320@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114a94aef44b83054fbd1ef8" X-Trace: blaine.gmane.org 1495048583 19274 195.159.176.226 (17 May 2017 19:16:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 19:16:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11357-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 17 21:16:19 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dB4Ql-0004uS-5Z for gllmg-musl@m.gmane.org; Wed, 17 May 2017 21:16:19 +0200 Original-Received: (qmail 5677 invoked by uid 550); 17 May 2017 19:16:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5659 invoked from network); 17 May 2017 19:16:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=6H0vOxUsJXRXFOBIQHQNpUl5VWHcMjW/t531vDpMWnQ=; b=aVAQa4zoEO8ZuZX+atwmDiCnSyJeB4Mfc4pbnNmTBH3ispTAYYE/WwhK00GT0q6KsQ HZipQUIB+jcaDPIcemu5thWlLV3eGwzY/1kxnlR+acQh0xGM4ErAJcHZnRthy0ssoOu/ WhIB/X3zZ3aJN3N2t4FqHEk0CVO5bFdCPpw1hcK4BsATel8kD5BWNmrojVCz6AGAMCCx dckjHgbVM/thCU5wonPw75Ce3DpXHDuKOXNmBCKcp0nV7BkNoZSXl2/3DT+8l7Ey7jiQ 9OWgXBTX2PLCTxyyxr5AhSGk/xcJKszHmMSWjMn3a6uzLXct53NcSHTL9RKecfuew3OP 4yig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6H0vOxUsJXRXFOBIQHQNpUl5VWHcMjW/t531vDpMWnQ=; b=TdLVbuMpX+Gz4fMrF2zopoNK8WZzFJ3Dq8xmo8wqMWb2zVubYhInZd6I6NRcZzRXNL ZHKzCMXrLaDqZTtoCsgrVkPB1H4qBVq4lgsTXLtsAXoCIk92qaTSX/JegC2HKAalyxKu NiuSEXwM5TH9FgSCts1W3HzpxLsnwpmsbcmJbMo0bSh4vfuf9d+xwE9DC4OgS0IvsqNu e+LxYvmL7kaQsO/CJ02YU4OkznzK63q3ec8RIGF+FMKdvwY4VeTQB3wFEKPcCmlVfDet uuPqZYSvpWzJuIbsYFaqqBGnGdKPiHQ6wQ2OBBDE5D3AYo8+8LCaaA9W6ceTHxOD/5pF 63Ng== X-Gm-Message-State: AODbwcCqrLWZVnk/G0Kbe1esFgXL5xsOyzJedMb6ST5Lo5GHs9d0P1V6 789L7sZZ+RD5itkn/TSpfRViKMN2PQ== X-Received: by 10.55.71.139 with SMTP id u133mr297096qka.317.1495048570291; Wed, 17 May 2017 12:16:10 -0700 (PDT) In-Reply-To: <20170517190705.GM6320@example.net> Xref: news.gmane.org gmane.linux.lib.musl.general:11342 Archived-At: --001a114a94aef44b83054fbd1ef8 Content-Type: text/plain; charset="UTF-8" On Wed, May 17, 2017 at 2:07 PM, wrote: > On Wed, May 17, 2017 at 12:24:28PM -0400, Rich Felker wrote: > > > >>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan wrote: > > > >>> > Hi there - I was wondering if it's possible to somehow set > argv[0] when > > > >>> > calling the dynamic linker to load a program. > > > > >>> Set argv[0] to whatever you need when you exec*() the dynamic > loader, > > > >>> which is straightforward with a binary wrapper (not with a shell). > > > >>> > > > >>> A binary wrapper also adds less overhead then going through a > shell. > > > > >>> Rune > > > a completely reasonable and recommended way for deploying dynamic > > linked apps in a self-contained way that doesn't depend on musl libc > > on the host. Unfortunately there's no way to set argv[0] like you want > > We do deploy dynamic linked apps without any dependencies on the libraries > on the host. It works just fine with musl-as-it-is, including the > questionably designed applications like busybox and gcc who > analyze argv[0]. > > > at this time. Perhaps adding an option like --argv0=foo would be > > appropriate. > > What would be the justification for adding the supporting code (to every > instance of the dynamic loader)? > > It looks like --argv0=foo is meant to overcome a specific limitation in > bourne shell, in a specific context where the task can be solved easily > and generally better without involving the bourne shell in the first hand. > > I would like to see an example of a situation where a wrapper in C (or > any language allowing setting of argv[0]) is less appropriate? > > If one really has a reason to express the wrapper in sh, a one-liner in > C and an extra exec from the shell (much cheaper than starting the > shell itself was) is sufficient to make it work. > > Rune > > Hi Rune - would you mind sharing some tips on doing that? I wrote and compiled a short program that just dumps the elements in argv, then a wrapper program that figures out the needed paths for libc, real binary, etc, but it seems like argv[0] gets reset by the dynamic loader. I'm calling execve with the path to the libc.so, and argv is somenthing like: argv[0] - desired process name argv[1] - full path to the real binary argv[2...] arguments The 'real' binary is loaded and ran, but winds up printing out: argv[0] - full path to the real binary argv[1...] arguments --001a114a94aef44b83054fbd1ef8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 17, 2017 at 2:07 PM, <u-uy74@aetey.se> wrote:=
On Wed, May 17, 2017 at= 12:24:28PM -0400, Rich Felker wrote:
> > >>> On Tue, May 16, 2017 at 08:38:56PM -0400, John Regan= wrote:
> > >>> > Hi there - I was wondering if it's possible= to somehow set argv[0] when
> > >>> > calling the dynamic linker to load a program.
> > >>> Set argv[0] to whatever you = need when you exec*() the dynamic loader,
> > >>> which is straightforward with a binary wrapper (not = with a shell).
> > >>>
> > >>> A binary wrapper also adds less overhead then going = through a shell.

> > >>> Rune

> a completely reasonable and recommended way for deploying dynamic
> linked apps in a self-contained way that doesn't depend on musl li= bc
> on the host. Unfortunately there's no way to set argv[0] like you = want

We do deploy dynamic linked apps without any dependencies on the lib= raries
on the host. It works just fine with musl-as-it-is, including the
questionably designed applications like busybox and gcc who
analyze argv[0].

> at this time. Perhaps adding an option like --argv0=3Dfoo would be
> appropriate.

What would be the justification for adding the supporting code (to e= very
instance of the dynamic loader)?

It looks like --argv0=3Dfoo is meant to overcome a specific limitation in bourne shell, in a specific context where the task can be solved easily
and generally better without involving the bourne shell in the first hand.<= br>
I would like to see an example of a situation where a wrapper in C (or
any language allowing setting of argv[0]) is less appropriate?

If one really has a reason to express the wrapper in sh, a one-liner in
C and an extra exec from the shell (much cheaper than starting the
shell itself was) is sufficient to make it work.

Rune

Hi Rune = - would you mind sharing some tips on doing that?

I wro= te and compiled a short program that just dumps the elements in argv, then = a wrapper program that figures out the needed paths for libc, real binary, = etc, but it seems like argv[0] gets reset by the dynamic loader.

I'm calling execve with the path to the libc.so, and argv is = somenthing like:

argv[0] - desired process name
argv[1] - full path to the real binary
argv[2...]= arguments

The 'real' binary is loaded and ran,= but winds up printing out:

= argv[0] - full path to the = real binary
argv[1...] arguments
--001a114a94aef44b83054fbd1ef8--