From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6872 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl and android Date: Tue, 20 Jan 2015 01:00:33 +0700 Message-ID: <20150120010033.253f53c9@sibserver.ru> References: <20150115161322.4ee903b7@sibserver.ru> <20150118133237.40beda09@sibserver.ru> <20150118064440.GA4574@brightrain.aerifal.cx> <20150118150119.1a80a4ba@sibserver.ru> <20150118164010.GC4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1421690081 23941 80.91.229.3 (19 Jan 2015 17:54:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Jan 2015 17:54:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6885-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 19 18:54:41 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YDGX9-0006aF-Er for gllmg-musl@m.gmane.org; Mon, 19 Jan 2015 18:54:39 +0100 Original-Received: (qmail 13422 invoked by uid 550); 19 Jan 2015 17:54:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13405 invoked from network); 19 Jan 2015 17:54:35 -0000 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <20150118164010.GC4574@brightrain.aerifal.cx> X-Mailer: claws-mail Xref: news.gmane.org gmane.linux.lib.musl.general:6872 Archived-At: =D0=92 Sun, 18 Jan 2015 11:40:10 -0500 Rich Felker =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sun, Jan 18, 2015 at 03:01:19PM +0700, =D0=A0=D1=8B=D1=81=D1=8C wrote: > > =D0=92 Sun, 18 Jan 2015 01:44:40 -0500 > > Rich Felker =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >=20 > > > On Sun, Jan 18, 2015 at 01:32:37PM +0700, =D0=A0=D1=8B=D1=81=D1=8C wr= ote: > > > > =D0=92 Thu, 15 Jan 2015 16:13:22 +0700 > > > > =D0=A0=D1=8B=D1=81=D1=8C =D0=BF=D0=B8=D1=88=D0= =B5=D1=82: > > > >=20 > > > > > Hello all! > > > > >=20 > > > > > Are there any efforts or even a project which aims to port > > > > > musl to android platform? > > > > >=20 > > > > > For a year I slowly had built and running a couple of C tty > > > > > only programs such as iptables, tcpdump and of course busybox > > > > > and many others including my own with musl libc linked > > > > > statically. They work perfectly (no much differences between > > > > > an ARM phone and, for example, raspberry pi SoC) but a few > > > > > items I missed: > > > > >=20 > > > > > + Proper DNS resolving is not available > > > > > + Translation of android special user names is not done > > > > >=20 > > > > > As an advanced Linux user I know that android is not friendly > > > > > enough to plain C stuff and it's libc is even not finished > > > > > now so I aimed to port at least listed things to musl. > > > > >=20 > > > > > Because I am not going beyond listed items, a patch can be > > > > > developed just to support these inside musl-linked binaries. > > > > >=20 > > > > > I am first here or there is already someone who done this > > > > > before? > > > >=20 > > > > I made a patch to implement all three things for musl on > > > > android. > > > >=20 > > > > I do not post it here as attachment to this mail because it > > > > normally should not be integrated with musl. The patch itself > > > > is here: > > > > http://lynxlynx.tk/prg/patches/musl-1.1.4_android.patch, notes > > > > about it: http://lynxlynx.tk/eng/musl_android/. > > > >=20 > > > > Patch is invasive enough I think and not optimized and I agree > > > > with Rich that it must go as a special treat. I tried however > > > > move away all translating code to src/android and headers to > > > > include/android. > > > >=20 > > > > Patch is still in it's alpha stage, and probably will be changed > > > > often. > > > >=20 > > > > Modifications made for musl 1.1.4. > > > >=20 > > > > If anyone interested to audit it - welcome! > > >=20 > > > Thanks. If nothing else, this is very informative as to how > > > Android does things. I noticed a couple things that could be a > > > lot less invasive, I think, particularly the builtin > > > users/groups. Couldn't you just fmemopen() a constant string > > > inside libc in place of /etc/passwd or /etc/group and use the > > > existing code to parse it? > >=20 > > This sounds more interesting idea, I forgot that get*ent() open fd > > and there is fmemopen() function. But app_/ux_ax names still need a > > dedicated translation function, probably the same code which will > > form a passwd-like string and feed it into get*ent(). >=20 > The intent is that get{gr,pw}{nam,uid} will eventually support > alternate backends via sending a request and receiving a response in > passwd/group line format. On normal systems this would take place via > a unix socket in some reasonable standard directory, but for Android > you could in principle build a reply mechanism into the binary in > place of it. Note that this would probably not support get{pw,gr}ent > enumeration, but I don't see that as a problem. Traditionally > enumeration does not work with backends like nis or ldap, as far as I > know, and it would be an unreasonable/abusive idiom on such large user > databases. >=20 > > > Another general question I have is why can't the /system issue be > > > fixed? Is there any good reason Android doesn't have symlinks like > > > /bin->/system/bin, /etc->/system/etc, /lib->/system/lib, > > > /tmp->/data/tmp, etc.? The gratuitous incompatibility is really > > > disgusting. > >=20 > > First, android has /etc -> /system/etc in place, but, > > unfortunately, no more :( > >=20 > > I made /etc -> /system/etc change just because I distrust symlinks > > when doing security things. It is usually stable across devices, > > but it's just symlink. > >=20 > > It even does not have usual Unix /tmp directory or it's surrogate > > somewhere in filesystem. /data/tmp is my adoption, though it's > > non-standard on android. > >=20 > > Second, android has a very different bootup process, and all those > > links in / are created during bootup (on a tmpfs?). Sadly only /etc > > is defined by android developers to be symlink to /system/etc. > >=20 > > Third, there are probably many differences between many android > > device vendors, android OS types (different android versions > > including ancient ones, different android forks that exist today, > > vendor customisations of fs layout and in future many others). In > > fact, android is _very_ fragmented OS. > >=20 > > All this is based on my experience with some android devices I > > working (and worked) with. >=20 > If / is a tmpfs, I don't see why proper symlinks can't be created, or > why /tmp can't just be created as a directory on / or as another tmpfs > mount on /tmp. Obviously you can't do these kinds of things as a > normal application installing on Android, but if you're doing your own > system programming on Android or if you have root, this seems like the > obvious correct fix... >=20 > I'd really like to hear from the Android side what their motive is for > breaking this by not providing the proper symlinks. >=20 > Rich I talked about android as by default an unprivileged user, i.e. most android devices are shipped so that owner of device cannot modify certain firmware parts and cannot get root privilege. Android developers decided to hide script that creates such a layout into initramfs which is hard to modify on most devices (certain vendor customisations apply, most do that via undescribed proprietary boot formats which are flashed directly onto boot partition). Of course an ordinary user is waaay far away from a right to modify it without dirty hacks, and / tmpfs has permissions not to create any inodes by unprivileged users and in fact is mounted readonly. The "correct fix" is another hardish thing: every such device must be hacked, and there must be a point from where you can start your own rc.local. initramfs is not a friend, and on most devices rooted with supersu (a common proprietary su(1) variant for android with graphical asking interface) there is /system/etc/install-recovery.sh from where you can invoke (or even have it as symlink) your rc.local. It's not portable though (I had seen device which cannot be rooted at all because vendor locked bootloader completely, or devices which are not reacted on this file presence in any form) ------------ I still see android issue as a separate one, so patch code in _any_ form must not go into main musl. If it go, then you must detect somehow are you running on android or on regular system. One possible way I'm seeing now is that environment variable ANDROID_PROPERTY_WORKSPACE, it's presence is that you're likely on android. In any other things, android is very fragmented. And there is another completely unrelated code for any normal systems, like this code querying mmaped file. I think this code or even whole musl should be ported to android as a separate project, or even musl should replace bionic in future android (or at least in it's forks). Reason is that android changes are too invasive. This is output of "ls -la /" from CyanogenMod 10.1 (no much differences from original android): # ls -la / drwxr-xr-x root root 2015-01-15 02:08 acct drwxrwx--x system cache 2013-09-27 15:00 cache -rwxr-x--- root root 268176 1970-01-01 07:00 charger dr-x------ root root 2015-01-15 02:08 config lrwxrwxrwx root root 2015-01-15 02:08 d -> /sys/kernel/deb= ug drwxrwx--x system system 2014-11-12 14:20 data -rw-r--r-- root root 136 1970-01-01 07:00 default.prop drwxr-xr-x root root 2015-01-15 02:08 dev drwxrwxr-x radio system 2013-01-08 22:44 efs lrwxrwxrwx root root 2015-01-15 02:08 etc -> /system/etc lrwxrwxrwx root root 2015-01-15 02:08 extSdCard -> /storag= e/sdcard1 -rw-r----- root root 1178 1970-01-01 07:00 fstab.espresso10 -rwxr-x--- root root 113592 1970-01-01 07:00 init -rwxr-x--- root root 1288 1970-01-01 07:00 init.cm.rc -rwxr-x--- root root 13512 1970-01-01 07:00 init.espresso10.rc -rwxr-x--- root root 3570 1970-01-01 07:00 init.espresso10.usb.= rc -rwxr-x--- root root 2770 1970-01-01 07:00 init.goldfish.rc -rwxr-x--- root root 21827 1970-01-01 07:00 init.rc -rwxr-x--- root root 301 1970-01-01 07:00 init.superuser.rc -rwxr-x--- root root 1795 1970-01-01 07:00 init.trace.rc -rwxr-x--- root root 3947 1970-01-01 07:00 init.usb.rc drwxrwxr-x root system 2015-01-15 02:08 mnt dr-xr-xr-x root root 1970-01-01 07:00 proc drwxr-xr-x root root 1970-01-01 07:00 res drwx------ root root 2013-09-24 09:37 root drwxr-x--- root root 1970-01-01 07:00 sbin lrwxrwxrwx root root 2015-01-15 02:08 sdcard -> /storage/e= mulated/legacy dr-xr-x--- system sdcard_r 2015-01-15 02:08 storage drwxr-xr-x root root 2015-01-15 02:08 sys drwxr-xr-x root root 2014-02-20 09:47 system -rw-r--r-- root root 1993 1970-01-01 07:00 ueventd.espresso10.rc -rw-r--r-- root root 272 1970-01-01 07:00 ueventd.goldfish.rc -rw-r--r-- root root 5897 1970-01-01 07:00 ueventd.rc lrwxrwxrwx root root 2015-01-15 02:08 usbdisk0 -> /storage= /usbdisk0 lrwxrwxrwx root root 2015-01-15 02:08 vendor -> /system/ve= ndor Note files with epoch time - they're copied into this space when system boots.