From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Android port of Emacs Date: Sat, 01 Jul 2023 14:13:48 +0000 Message-ID: <215b00d25949851ddde8@heytings.org> References: <83v8fnslfz.fsf@gnu.org> <83edmask4z.fsf@gnu.org> <5c02371a-3c42-de66-70b7-4ed0d88cc3fa@gutov.dev> <87cz1td0ku.fsf@yahoo.com> <87cz1ta5fr.fsf@telefonica.net> <87edm645yy.fsf@yahoo.com> <87mt0ryqlg.fsf@yahoo.com> <2aa76ba11fdd1c81b2f0@heytings.org> <87o7l6y2zf.fsf@yahoo.com> <30832e8647c0d343f7d8@heytings.org> <87fs6d91rr.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="310"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?UTF-8?Q?=C3=93scar_Fuentes?= , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 01 16:14:45 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qFbN7-000APc-Oo for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Jul 2023 16:14:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qFbMK-0006My-5i; Sat, 01 Jul 2023 10:13:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFbMI-0006Mm-T2 for emacs-devel@gnu.org; Sat, 01 Jul 2023 10:13:54 -0400 Original-Received: from heytings.org ([95.142.160.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFbMH-0004AI-5L for emacs-devel@gnu.org; Sat, 01 Jul 2023 10:13:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1688220829; bh=n/XNIzy6NfePNQ7/TQFNnvTbLWW3z3Zo96euDKO2bgA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=2wVRRwpF6LWqlO9bhJ/EMYcgB5oFVvrEBdfqzJxw8uv3tgJFir+VSflpJR+O2N9x8 TWKtfdoXQlLj7xwDCzSTXowMT/4oMCQ5MxzeVwev4/RokPrLnQDOuHK77cNeVp5JGC C56SpulIcYFn8ZL0wmXqOaI+wkhQqpyaCWxcUPBRGJF3FOYAdksFdMuuwY2IqNrimm tFdtAEUMQafqkjG+cStdLSImtyMgwMfYjisqoSX3oeqQoXS4nr7hzKZmZRtzT+KFhN TO2FPll4aJfblGcrbatJL43kPQRNf2G/r4wgWSIUUt03YjlQYqt/8pW7vhU/yQOI7y GiB5yXhRA+wmA== In-Reply-To: <87fs6d91rr.fsf@yahoo.com> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307329 Archived-At: > 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.