runtime: Always use link target for /proc/self/exe #1168
Conversation
When running an AppImage under [gcompat][0] (e.g. on Alpine Linux),
`fopen("/proc/self/exe", "rb")` opens the dynamic linker (e.g.
`/lib/ld-musl-x86_64.so.1`) instead of the AppImage itself. However,
`readlink("/proc/self/exe", ...)` does give the path to the AppImage as
expected, even under gcompat.
This commit fixes this problem by always using the link target for
`/proc/self/exe` in places that read the AppImage instead of the link
itself. Without this commit, running an AppImage under gcompat results
in [the error message "This doesn't look like a squashfs image." from
squashfuse][1]. With this commit, AppImages run as expected under
gcompat.
In order to make `--appimage-help` and
`--appimage-portable-{home,config}` work under gcompat, I also move the
calculation of the `fullpath` variable in `main()` to earlier in the
function and change `print_help()` and `portable_option()` to use it
instead of calculating the fullpath separately. (When
`$TARGET_APPIMAGE` is set, since `realpath()` is (already) used instead
of `readlink()` in that case, this change could result in a different
path being used in help output and when _creating_ the portable home and
config directories with the respective command line options, but
`fullpath` is already being used to find existing portable directories
when running an AppImage, so this should not affect existing portable
installations.) For consistency, I also rename the `fullpath` variable
in `main()` and the corresponding arguments in `print_help()` and
`portable_option()` to `appimage_fullpath`.
Fixes AppImage#1015 on Alpine Linux systems with gcompat installed, for
AppImages made with this commit applied.
Tested on Alpine Linux edge x86_64 and postmarketOS (based on Alpine)
edge aarch64.
[0]: https://git.adelielinux.org/adelie/gcompat/
[1]: https://github.com/vasi/squashfuse/blob/e51978cd6bb5c4d16fae9eee43d0b258f570bb0f/util.c#L81-L82
|
Thanks for pointing this out. I wasn't aware of gcompat, a library which provides glibc-compatible APIs for use on musl libc systems. Opening |
|
You should open an issue with |
|
Agree, if gcompat is meant to be compatible with glibc, then it should behave like it. |
|
No. But someone should let them know about it. |
There was a problem hiding this comment.
Looks good at a first glance. @probonopd should test a few AppImages built with the appimagetool from this PR, he's the bug finding specialist.
|
Still to be tested using the build from https://github.com/AppImage/AppImageKit/actions/runs/1780621637 |
I think this causes race conditions when the binary is renamed between the reading of the link and the opening of the path that was read. fopen() directly doesn't seem to possibly cause since it uses some black magic to not actually read the path but somehow accesses the inode directly or such, at least if I recall correctly. (Basically renaming the program binary after it is launched in just the right moment will cause breakage with this merge request when it wouldn't have before.) I would therefore suggest this has a notable downside and shouldn't be merged. |
When running an AppImage under gcompat (e.g. on Alpine Linux),
fopen("/proc/self/exe", "rb")opens the dynamic linker (e.g./lib/ld-musl-x86_64.so.1) instead of the AppImage itself. However,readlink("/proc/self/exe", ...)does give the path to the AppImage as expected, even under gcompat.This commit fixes this problem by always using the link target for
/proc/self/exein places that read the AppImage instead of the link itself. Without this commit, running an AppImage under gcompat results in the error message "This doesn't look like a squashfs image." from squashfuse. With this commit, AppImages run as expected under gcompat.In order to make
--appimage-helpand--appimage-portable-{home,config}work under gcompat, I also move the calculation of thefullpathvariable inmain()to earlier in the function and changeprint_help()andportable_option()to use it instead of calculating the fullpath separately. (When$TARGET_APPIMAGEis set, sincerealpath()is (already) used instead ofreadlink()in that case, this change could result in a different path being used in help output and when creating the portable home and config directories with the respective command line options, butfullpathis already being used to find existing portable directories when running an AppImage, so this should not affect existing portable installations.) For consistency, I also rename thefullpathvariable inmain()and the corresponding arguments inprint_help()andportable_option()toappimage_fullpath.Fixes #1015 on Alpine Linux systems with gcompat installed, for AppImages made with this changeset applied.
Tested on Alpine Linux edge x86_64 and postmarketOS (based on Alpine) edge aarch64.