If we got __program_executable_name, it means the /proc-esque methods
are going to return the path of the loader rather than the path of the
binary, so do not use them in this case.
If the passed path is absolute, use it as-is. Otherwise, copy it into
the buffer with getcwd prepended. The sys_faccessat call should be
redundant; if TryPath fails, it probably failed because getcwd() was too
long, so just use the relative path and accept that chdir will break
things.
On that note, TryPath now fails prior to the sys_faccessat if getcwd()
is too long, and otherwise behaves the way the code used to. The version
I wrote before this change would have always succeeded on a truncated
path assuming the relative path could have been accessed. The original
version would have succeeded on a truncated path if there happened to be
a file at that path that could be accessed.
This change also backs out the setugid loader check for /dev/fd path.
For now, we fail open; if for some reason we are invoked set-id by the
loader, we just assume that the user knows what they are doing and do
not attempt to second-guess them, beyond politely declining to trust
argv[0] or the environment.
The loader implementing it was never minted, so it seems reasonable not
to keep support for it indefinitely. But it seems impolite to break the
prerelease loaders people may have been using between releases.
Fixes a regression in GetProgramExecutableName on Linux against old
loaders. In the loader case, /proc/self/exe gives the loader's path.
We tried to detect this by checking for `/usr/bin/ape`. But that is
only one of the possible places the loader could be.
TryPath with com==1 tries both non-com and com, so the checks were
redundant.
With com==0, there is no reason to copy to the buffer if the initial
access fails.
Somehow or another, I previously had missed `BUILD.mk` files.
In the process I found a few straggler cases where the modeline was
different from the file, including one very involved manual fix where a
file had been treated like it was ts=2 and ts=8 on separate occasions.
The commit history in the PR shows the gory details; the BUILD.mk was
automated, everything else was mostly manual.
The ape loader now passes the program executable name directly as a
register. `x2` is used on aarch64, `%rdx` on x86_64. This is passed
as the third argument to `cosmo()` (M1) or `Launch` (non-M1) and is
assigned to the global `__program_executable_name`.
`GetProgramExecutableName` now returns this global's value, setting
it if it is initially null. `InitProgramExecutableName` first tries
exotic, secure methods: `KERN_PROC_PATHNAME` on FreeBSD/NetBSD, and
`/proc` on Linux. If those produce a reasonable response (i.e., not
`"/usr/bin/ape"`, which happens with the loader before this change),
that is used. Otherwise, if `issetugid()`, the empty string is used.
Otherwise, the old argv/envp parsing code is run.
The value returned from the loader is always the full absolute path
of the binary to be executed, having passed through `realpath`. For
the non-M1 loader, this necessitated writing `RealPath`, which uses
`readlinkat` of `"/proc/self/fd/[progfd]"` on Linux, `F_GETPATH` on
Xnu, and the `__realpath` syscall on OpenBSD. On FreeBSD/NetBSD, it
punts to `GetProgramExecutableName`, which is secure on those OSes.
With the loader, all platforms now have a secure program executable
name. With no loader or an old loader, everything still works as it
did, but setuid/setgid is not supported if the insecure pathfinding
code would have been needed.
Fixes#991.
Using this shell script:
#!/bin/sh
mkdir -p exe
for f in $(findpe); do
if [ -e exe/${f##*/}.exe ]; then
cp $f exe/${f##*/}-$(rand64).exe
else
cp $f exe/${f##*/}.exe
fi
done
rm -f /mnt/videos/microsoft.zip
zip -rj6 /mnt/videos/microsoft.zip exe
echo /mnt/videos/microsoft.zip
Helps file reports with Microsoft about incorrect AV detections.
See #1003
Please use https://github.com/mozilla-Ocho/llamafile which is better,
newer, and built on cosmocc. If you need the RadPajama model, file an
issue with llamafile asking for support.
We have received multiple reports of GCC breaking builds when compiler
flags like `-std=c11` were being passed. The workaround until the next
release is to simply not define `__STRICT_ANSI__` which is a bad idea.
