[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Mar 2013 23:01:18 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: program_invocation_name
On Sun, Mar 24, 2013 at 03:49:54AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...ifal.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
