program_invocation_name

program_invocation_name

[Rich Felker]

Hi,

I've seen some demand again for the GNU extension
program_invocation_name (and program_invocation_short_name) and I'm
not totally opposed to adding them (although the latter adds some ugly
nontrivial startup cost), but I'm also frustrated that they're not
documented properly. The glibc manual defines them as:

— Variable: char * program_invocation_name
This variable's value is the name that was used to invoke the program
running in the current process. It is the same as argv[0]. Note that
this is not necessarily a useful file name; often it contains no
directory names. See Program Arguments.

— Variable: char * program_invocation_short_name
This variable's value is the name that was used to invoke the program
running in the current process, with directory names removed. (That is
to say, it is the same as program_invocation_name minus everything up
to the last slash, if any.)

But my understanding is that these descriptions are false, and that
program_invocation_name is just a pointer to the same storage as
argv[0], and program_invocation_short_name points to the tail of
argv[0]. In this case, modifications to argv[0] would be reflected
through these pointers. Is that correct and reasonable? The
alternative, copying a string that could be up to ARG_MAX to its own
storage, is obviously nasty and unwanted.

If we do add program_invocation_short_name, what should the size/speed
tradeoff be? I really don't want to make strrchr a mandatory part of
the startup code; would a trivial loop to do the job suffice?

for (s=t=argv[0]; *t; t++) if (*t=='/') s=t+1;

Rich


P.S. If we do add these, we could certainly add the BSD names too as
aliases.

Re: program_invocation_name

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2013-03-23 20:16:18 -0400]:
> ??? Variable: char * program_invocation_name
> ??? Variable: char * program_invocation_short_name

these look ridiculous..

> But my understanding is that these descriptions are false, and that
> program_invocation_name is just a pointer to the same storage as
> argv[0], and program_invocation_short_name points to the tail of
> argv[0]. In this case, modifications to argv[0] would be reflected
> through these pointers. Is that correct and reasonable? The

yes, that's what glibc does so these
can be gibberish if argv[0] is changed

> If we do add program_invocation_short_name, what should the size/speed
> tradeoff be? I really don't want to make strrchr a mandatory part of
> the startup code; would a trivial loop to do the job suffice?
> 
> for (s=t=argv[0]; *t; t++) if (*t=='/') s=t+1;

yes that makes sense assuming argv[0]!=0

> P.S. If we do add these, we could certainly add the BSD names too as
> aliases.

bsd only has the short version (__progname)
and openbsd does the copy (into a NAME_MAX sized buffer)
while freebsd does not

Re: program_invocation_name

[Rich Felker]

On Sun, Mar 24, 2013 at 03:49:54AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2013-03-23 20:16:18 -0400]:
> > ??? Variable: char * program_invocation_name
> > ??? Variable: char * program_invocation_short_name
> 
> these look ridiculous..

I agree, but there's a good bit of software using them, and for the
purpose of syslog, dynamic linker stuff, etc. it might be nice to have
them for internal use too.

> > But my understanding is that these descriptions are false, and that
> > program_invocation_name is just a pointer to the same storage as
> > argv[0], and program_invocation_short_name points to the tail of
> > argv[0]. In this case, modifications to argv[0] would be reflected
> > through these pointers. Is that correct and reasonable? The
> 
> yes, that's what glibc does so these
> can be gibberish if argv[0] is changed

OK that's what I expected.

By the way, an amusing vuln: if the end of argv is overwritten, the
environment (which immediately follows) is exposed world-readable
through /proc/self/cmdline. I tried overwriting everything all the way
up to the user/kernel boundary in hopes that cmdline would also expose
the low part of kernel memory, but the kernel detected this and
refused to show anything.

> > If we do add program_invocation_short_name, what should the size/speed
> > tradeoff be? I really don't want to make strrchr a mandatory part of
> > the startup code; would a trivial loop to do the job suffice?
> > 
> > for (s=t=argv[0]; *t; t++) if (*t=='/') s=t+1;
> 
> yes that makes sense assuming argv[0]!=0

I don't think argv[0]==0 is permitted, but if it is possible, we could
add a check.

> > P.S. If we do add these, we could certainly add the BSD names too as
> > aliases.
> 
> bsd only has the short version (__progname)

Doesn't it also have __progname_full or something?

> and openbsd does the copy (into a NAME_MAX sized buffer)
> while freebsd does not

I can see how there would be mild advantages to copying it, but I
think they're outweighed by the bloat. As long as no library code is
_trusting_ the contents of this string (which would be stupid to do),
I don't see any security benefit to saving a copy.

Rich

Re: program_invocation_name

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2013-03-23 23:01:18 -0400]:
> > > for (s=t=argv[0]; *t; t++) if (*t=='/') s=t+1;
> > 
> > yes that makes sense assuming argv[0]!=0
> 
> I don't think argv[0]==0 is permitted, but if it is possible, we could
> add a check.

execl("./foo", (char*)0, (char*)0);

works here (argc==0 and argv[0]==0 in the executed process)

> > > P.S. If we do add these, we could certainly add the BSD names too as
> > > aliases.
> > 
> > bsd only has the short version (__progname)
> 
> Doesn't it also have __progname_full or something?

no, that's a gnu invention, added at the same time
as the program_invocation_name things

but yes we should probably support both if we support any

Re: program_invocation_name

[Daniel Cegiełka]

Hi,
The topic was already discussed and we found that musl will not be a
second glibc (with ugly solutions). One can always use:

char *progname; /* __progname */

int main()
{
  progname = basename(argv[0]);

...

best regards,
Daniel