|
From: | Gregory Heytings |
Subject: | Re: Android port of Emacs |
Date: | Sat, 01 Jul 2023 14:13:48 +0000 |
Emacs is a better terminal emulator than Termux.
That's a too assertive statement. _Your opinion_ is that Emacs is a better terminal emulator than Termux, and that's fine. Others have dissenting, and equally respectable, opinions.
Even if everyone agreed that Emacs is a better terminal emulator than Termux, it would not change the fact that Emacs is not a suitable replacement for programs such as GIMP or Audacity, which means that users who would want to use both Emacs and one of these programs would have to install the Termux distro twice. Which is the problem I pointed to initially (or rather, a part of that problem).
The correct conclusion would have been that I don't want to play by your "you should first demonstrate your technical knowledge before speaking here" rule.So why are you making (false) claims about the _technical_ details of process execution?
I am not. FTR, what I said is "in all likelihood that hole in Android's security policy [the fact that the "write xor execute" policy can be circumvented with a hack] will be patched sooner or later". I maintain what I said. Obviously I can't read in Android developer's minds, so I don't know how they will do that. It is also possible that they will not do anything, but if they decide to do something, they could, for example, set kernel.yama.ptrace_scope=2, and grant the ptrace capability only to a few selected executables.
I am not interested in considering the limitations of Google Play Store policy, for example.
The Google Play Store policy is not what is being discussed here, it does not directly impact apps that are installed on an Android device. What is being discussed is Android's security policy, which is (or rather: will be) enforced on Android devices, independently of the origin of the app.
And, by the way, why do you provide an android-use-exec-loader variable to disable that hack, and do you explain in its docstring that it "may prove to be problematic for various different reasons", if it is indeed a good solution? Its most obvious limit, apart from the overhead it introduces, is that, given that a ptrace'd process cannot ptrace'd again, it becomes impossible to use a debugger with that hack.gdbserver is installed in /system/bin, so it can be run without process tracing.
That is inaccurate and misleading.First, you may be aware that GDB was deprecated, and has now been removed from Android. What Android now provides instead is lldb-server.
Second, lldb-server is not always installed in /system/bin, on some/many devices it is not installed at all. When it is not installed, it can be manually installed in /data/local/tmp, but in that case it cannot be used by Emacs.
Third, even when lldb-server is installed in /system/bin, the main problem, which is not to run a debugger without ptrace'ing the debugger itself, but to start the program that is being debugged, is not solved: the debugger has to exec that program, but it is in a writable directory, so that will be denied by the "write xor execute" security policy.
And you do not explain why you provide an android-use-exec-loader variable to disable the hack, and why you explain in its docstring that it "may prove to be problematic for various different reasons", if it is indeed a good solution.
Besides that, if su is installed on the Android device in question (which is uncommon), Emacs can simply change its security context to `trusted_app'. For obvious reasons, su cannot work if it is being ptraced.
That's irrelevant: this whole discussion, and your hack, are pointless if we assume rooted Android devices, on which by definition all security measures can be turned off.
[Prev in Thread] | Current Thread | [Next in Thread] |