-
-
Notifications
You must be signed in to change notification settings - Fork 561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: Always use link target for /proc/self/exe #1168
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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/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. 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 thefullpath
variable inmain()
to earlier in the function and changeprint_help()
andportable_option()
to use it instead of calculating the fullpath separately. (When$TARGET_APPIMAGE
is 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, butfullpath
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 thefullpath
variable 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.