Re: Android port of Emacs

[Gregory Heytings <gregory@heytings.org>]

> 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.