Date:Thu, 9 Jan 2025 13:52:01 +
From:David Holland
Message-ID:
| It absolutely is. argv[0] is provided by the program that calls
| execve, which for ordinary 3rd-party application software that wants
| this feature is either the shell or a shell substitute
On Mon, Jan 06, 2025 at 06:50:25PM +0100, Jean-Yves Migeon (NetBSD) wrote:
> > For the sake of argument, I wrote the code, stuck it in /usr/local/bin,
> > and ran it in various ways, first from sh:
>
> This is not a shell matter.
It absolutely is. argv[0] is provided by the program that calls
> On Jan 5, 2025, at 9:24 PM, David Holland wrote:
>
> On Sun, Jan 05, 2025 at 04:24:23AM +0100, Jean-Yves Migeon (NetBSD) wrote:
>> Also all argv[] strings can be modifiable by callee. pathname of the
>> execution (as passed to execve(2) or like) is not.
>
> So?
>
> (also, that's UB in C so th
Le 06/01/2025 à 03:24, David Holland a écrit :
On Sun, Jan 05, 2025 at 04:24:23AM +0100, Jean-Yves Migeon (NetBSD) wrote:
> argv[0] (by C99) is just program's name, and has no warranty of
> representing (even a substring of) the exec path; and has its use in that
> regard, e.g. crunchgen(1)
On Mon, Jan 06, 2025 at 02:24:35AM +, David Holland wrote:
> On Sun, Jan 05, 2025 at 04:24:23AM +0100, Jean-Yves Migeon (NetBSD) wrote:
> > > Under normal circumstances the callee can use argv[0], though
> > > admittedly it's a bit of a nuisance since it requires examining $PATH
> > > if the
On Sun, Jan 05, 2025 at 04:24:23AM +0100, Jean-Yves Migeon (NetBSD) wrote:
> > Under normal circumstances the callee can use argv[0], though
> > admittedly it's a bit of a nuisance since it requires examining $PATH
> > if there's no / in the string. One could certainly make a library
> > functi
>> The only cases where this isn't true are setugid bins, where argv[0]
>> might be malicious, and these cases shouldn't be using any of the
>> other referenced mechanisms either as most of them are subject to
>> races or other interference.
> Pretty much "any" binary, not just setugid.
Yes, but f
Le 04/01/2025 à 11:22, David Holland a écrit :
Under normal circumstances the callee can use argv[0], though
admittedly it's a bit of a nuisance since it requires examining $PATH
if there's no / in the string. One could certainly make a library
function that does that though.
argv[0] (by C99) i
On Sat, Jan 04, 2025 at 10:45:11AM +, Taylor R Campbell wrote:
> > Under normal circumstances the callee can use argv[0], though
> > admittedly it's a bit of a nuisance since it requires examining $PATH
> > if there's no / in the string. One could certainly make a library
> > function that
Le 04/01/2025 à 07:52, Taylor R Campbell a écrit :
Date: Wed, 18 Dec 2024 19:26:50 +0100
From: "Jean-Yves Migeon (NetBSD)"
1 - As there is prior art elsewhere (getexecname(3)), unless there is a
specific (legal?) reason not to have the same name, I would reuse it (or
provide an alias) -- especia
> Date: Sat, 4 Jan 2025 10:22:01 +
> From: David Holland
>
> On Sat, Jan 04, 2025 at 06:52:38AM +, Taylor R Campbell wrote:
> > The point here is to grant the callee access to the exec path
> > _without_ cooperation by the caller.
> >
> > That way, the callee can find data files or l
On Sat, Jan 04, 2025 at 06:52:38AM +, Taylor R Campbell wrote:
> The point here is to grant the callee access to the exec path
> _without_ cooperation by the caller.
>
> That way, the callee can find data files or libraries relative to
> where it was found, without requiring the caller to
> Date: Wed, 18 Dec 2024 19:26:50 +0100
> From: "Jean-Yves Migeon (NetBSD)"
>
> I welcome such an addition; I had to deal with a problem alike in a
> "portable" way (...), and that ended up in a painful and fragile way. I
> have some remarks though, low tier (not blocking/critical).
> 1 - As t
Le 16/12/2024 à 23:45, Taylor R Campbell a écrit :
PROPOSAL: New libc function
const char *getexecpath(void);
returns the pathname that was passed to execve(2), unmodified.
Thoughts?
Hey Taylor,
I welcome such an addition; I had to deal with a problem alike in a
"portable" way (...
PROPOSAL: New libc function
const char *getexecpath(void);
returns the pathname that was passed to execve(2), unmodified.
Thoughts?
DETAILS:
This will be implemented by a new ELF auxiliary vector entry
AT_EXECPATH (or maybe AT_NETBSD_EXECPATH). Programs can use this to
get files rela
15 matches
Mail list logo
