From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6874 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl and android Date: Wed, 21 Jan 2015 17:34:03 +0700 Message-ID: <20150121173403.75ef5a15@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 1421836084 547 80.91.229.3 (21 Jan 2015 10:28:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Jan 2015 10:28:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6887-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 21 11:28:03 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 1YDsW2-0003xe-Te for gllmg-musl@m.gmane.org; Wed, 21 Jan 2015 11:28:03 +0100 Original-Received: (qmail 9352 invoked by uid 550); 21 Jan 2015 10:28:00 -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 9344 invoked from network); 21 Jan 2015 10:27:59 -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:6874 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 Ok, I posted a version that is completely new in uid/gid translation, which follows your suggestions. It was really easy to implement it (although somewhat tricky with _r functions at start) and no more malloc/free dances! It should be more sane now. Please see it (link is same): http://lynxlynx.tk/prg/patches/musl-1.1.4_android.patch As of previous version, I do not recommend it to be included in musl.