Please refrain from using titles that are more alarmist than the original title. If linking to something with an alarmist title (not the case here!), use a more neutral headline for your submission.
I guess with more reading they are saying they need to declare themselves as targeting android 9 or lower until they find a solution. At some point, I imagine, that will not be an option.
To some degree it should also be on Google to ensure that tightening security (or perceived tightening of security) doesn't break valid use cases.
edit: Ok, for some reason I can't reply, but I see the workaround is to write to another directory.
In any case - don't editorialize in your titles.
https://github.com/termux/termux-app/issues/1072#issuecommen...
"As i said on another issue, you should really start communicating this to users now , via as many channels as you can. I understand why you are doing what you do, but it is a big change and will annoy and/or confuse users however will you implement it. so getting people prepared now (ie as soon as possible, and before they have to do anything) will avoid a lot of angst and be in your best interests."
The "solution" is to publish 100s of different play store apps with Linux packages or to disable the ability to run installed programs.
In one project we work around this by shipping a tiny wrapper in the APK to exec that then uses dlopen() on the target, which is now built as a library.
Pretty sure a generic hack could be made to run unmodified executables this way. Certainly in the security community userland ELF loaders are very old news, even X11R6 had its own at one point
And then at some point you realize that, like Cygwin, you have built a system where fork() fails randomly by design.
And then Google blacklists both fork and exec.
I have a cron running on it that mails my notifications to me, a ssh server which my laptop use to send my backups on my phone, a go http server running a local app that I use in the mobile's browser, I'll often take screenshots on the phone, then scp them on the laptop, etc.
Am I missing something?
EDIT: I won't reply to each of you to not be floody, thanks everyone for the clarifications :)
It's only an issue if applications target Android 10 APIs. Termux still targets an older API version and is thus not yet affected by this issue. Eventually they'll need to target a newer version because the Google Play store specifies a minimum API version that applications need to use.
[1]: https://developer.android.com/distribute/best-practices/deve...
Long term, I can only assume targeting an old SDK will not be supported at some point.
The Termux maintainers have built their app to tell the operating system that Termux is only aware of how the Android 9 API works. So when you run Termux on your Android 10 device, the operating system tries to behave like it's Android 9. So it allows this.
They (Google) do this to ease the transition so that when a new version of Android is released, they don't force all developers everywhere to immediately fix all compatibility issues.
But they do want developers to do it eventually, so at some point in the future, they will probably stop allowing the Termux maintainers to upload an app that declares "I don't understand Android 10 yet".
Off-topic, but that's awesome! How do you get access to your notifications from Termux?
It basically give access to most permissions an app can get. The cool thing is that you allow the permission for termux, and then all you scripts can use them.
But yeah indeed, the notif2mail was quite a game changer, for me :) I had a big problem of spam calls/sms at some point, and this allowed me to get my notifications through my spam filter and remove the spam. I also use it to trigger desktop notification when my phone battery is low or full.
EDIT: oh, actually, it's not termux itself, but the addon Termux:API (which is a second app, from Play Store point of view). Also, the command to list notifications is `termux-notification-list`, but it doesn't appear in this documentation page, for some reason. All api executable start with `termux-`, so it's quite easy to list them from the shell.
To start cron when booting the phone, I had also to use an other addon, Termux:Boot : https://wiki.termux.com/wiki/Termux:Boot
There's alternatives Termux could take, which the Google issue tracker already mentions such as bundling the executables in the APK & using extractNativeLibs=true so they can be exec'd ( https://issuetracker.google.com/issues/128554619#comment4 ). They could use a loader that mmap's the code with PROT_EXEC but not PROT_WRITE, that also works (this is how JIT's work, and Android is obviously not breaking JITs anytime soon)
It's not entirely clear why Termux hasn't seemingly made any move on the alternative approaches raised a year ago (that's how old the issue is: https://github.com/termux/termux-app/issues/1072 ), and there's a bunch of nonsensical alarmist bullshit muddying up the waters which isn't helping.
Even if the workaround works, this would break apt install from non-termux repos, compiling and running with gcc, maybe Python packages installed with pip.
Google's intent here is to block code execution in the app home Dir. Any workaround would be a security violation and eventually stopped. How is this not killing Termux?
Google's actions are to block exec of writable code. What their _intentions_ are is pure speculation and detracts from the actual issue. Your claim is largely unsubstantiated & lacks evidence, particularly as Google recommended ways to continue to do exactly what you claim they are intending to block.
> The options in that issue aren't nearly as good.
How is using a PROT_EXEC mmap "not nearly as good"? It's the same end result. There's no technical banning of executing downloaded code. That's not what was done, and doing that would also break Chrome which should be glaringly obvious that Google isn't intending or going to do.
It takes a bit more effort, and it's not as "simple" as just exec'ing random stuff, but it's not without its own upsides as well (like not violating W^X, which is a _well_ proven security design)
The problem is that they don't want you mapping code from anywhere other than your strictly read only .apk.
There is no workaround proposed there other than shipping every single piece of executable code with the .apk.
Sure, you can workaround right now with proot or the like by creating your own executable loader, but who guarantees this works with Android 11? It is also a violation of their policy.
In fact, what they are saying there is that eventually fork and exec are going to be deprecated because they disalign with the Android process model.