wolfcw
Apple date command on ARM M1 not working as I expected
I need a little help here please - I am not sure if I am doing this correct or if it's expected that the apple date command should work or not.
Here are my findings on the M1:
1: when using date located in the local folder or in the system default location, fails
2: when using LD_PRELOAD it has no effect whereas DYLD_FORCE_FLAT_NAMESPACE and DYLD_INSERT_LIBRARIES
does work when using gdate
3: gdate (gnu coreutils) does work together with DYLD_FORCE_FLAT_NAMESPACE and DYLD_INSERT_LIBRARIES but not with LD_PRELOAD
Results (where I stripped the time but kept the day part of the log) - the system default date is set to 22 Feb by the system automatically.
➜ libfaketime git:(master) ✗ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=./src/libfaketime.1.dylib FAKETIME="-15d" gdate Tue Feb 7 ... 2023 ➜ libfaketime git:(master) ✗ LD_PRELOAD=./src/libfaketime.1.dylib FAKETIME="-15d" gdate Wed Feb 22 ... 2023 ➜ libfaketime git:(master) ✗ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=./src/libfaketime.1.dylib FAKETIME="-15d" date Wed 22 Feb 2023 ... ➜ libfaketime git:(master) ✗ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=./src/libfaketime.1.dylib FAKETIME="-15d" ./date Wed 22 Feb 2023 1... ➜ libfaketime git:(master) ✗ LD_PRELOAD=./src/libfaketime.1.dylib FAKETIME="-15d" ./date Wed 22 Feb 2023 ... ➜ libfaketime git:(master) ✗ LD_PRELOAD=./src/libfaketime.1.dylib FAKETIME="-15d" date Wed 22 Feb 2023 ... ➜ libfaketime git:(master) ✗
DYLD_INSERT_LIBRARIES is the way to go and seems to work fine with gdate on your system.
LD_PRELOAD is the environment variable for the linker found, e.g., on most Linux systems. It's not supposed to have any effect on macOS.
As far as Apple's date command/binary is concerned: In previous macOS versions it was sufficient to copy those files from a SIP-protected path to a local, unprotected one. However, more recent macOS versions apparently added additional security measures, and my guess is that something like "code signing" prevents library injection altogether. This should affect any kind of inserted libraries, not just libfaketime, and there might be macOS-version-specific tweaks to remove that kind of protection either system-wide or per application. Feel free to experiment. :-) However, if the system prevents libfaketime from being loaded at all for certain binaries, there's not much that can be done on libfaketime's side.
DYLD_INSERT_LIBRARIES is the way to go and seems to work fine with gdate on your system.
LD_PRELOAD is the environment variable for the linker found, e.g., on most Linux systems. It's not supposed to have any effect on macOS.
As far as Apple's date command/binary is concerned: In previous macOS versions it was sufficient to copy those files from a SIP-protected path to a local, unprotected one. However, more recent macOS versions apparently added additional security measures, and my guess is that something like "code signing" prevents library injection altogether. This should affect any kind of inserted libraries, not just libfaketime, and there might be macOS-version-specific tweaks to remove that kind of protection either system-wide or per application. Feel free to experiment. :-) However, if the system prevents libfaketime from being loaded at all for certain binaries, there's not much that can be done on libfaketime's side.
This is true. Can we update the readme for MacOS since copy files to non-sip path doesn't work? In addition, how to make macOS-version-specific tweaks to remove protection for specific application?
It's hard to find documentation on what Apple changes between macOS versions in this area, but I assume it is related to https://developer.apple.com/documentation/security/hardened_runtime, https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation, and https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables ... with the point being that Apple apparently progressively disables anything related to DYLD insertions as a security measure.
So do you mean that MacOS can only use faketime without SIP afterwards?