From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6875 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl and android Date: Wed, 21 Jan 2015 13:36:37 -0500 Message-ID: <20150121183637.GK4574@brightrain.aerifal.cx> References: <20150115161322.4ee903b7@sibserver.ru> <20150118133237.40beda09@sibserver.ru> <20150118064440.GA4574@brightrain.aerifal.cx> <20150118150119.1a80a4ba@sibserver.ru> <20150118164010.GC4574@brightrain.aerifal.cx> <20150121173403.75ef5a15@sibserver.ru> 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: 8bit X-Trace: ger.gmane.org 1421865416 19722 80.91.229.3 (21 Jan 2015 18:36:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Jan 2015 18:36:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6888-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 21 19:36:55 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 1YE098-00087j-DW for gllmg-musl@m.gmane.org; Wed, 21 Jan 2015 19:36:54 +0100 Original-Received: (qmail 30151 invoked by uid 550); 21 Jan 2015 18:36:52 -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 30140 invoked from network); 21 Jan 2015 18:36:51 -0000 Content-Disposition: inline In-Reply-To: <20150121173403.75ef5a15@sibserver.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6875 Archived-At: On Wed, Jan 21, 2015 at 05:34:03PM +0700, Рысь wrote: > В Sun, 18 Jan 2015 11:40:10 -0500 > Rich Felker пишет: > > > On Sun, Jan 18, 2015 at 03:01:19PM +0700, Рысь wrote: > > > В Sun, 18 Jan 2015 01:44:40 -0500 > > > Rich Felker пишет: > > > > > > > On Sun, Jan 18, 2015 at 01:32:37PM +0700, Рысь wrote: > > > > > В Thu, 15 Jan 2015 16:13:22 +0700 > > > > > Рысь пишет: > > > > > > > > > > > Hello all! > > > > > > > > > > > > Are there any efforts or even a project which aims to port > > > > > > musl to android platform? > > > > > > > > > > > > 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: > > > > > > > > > > > > + Proper DNS resolving is not available > > > > > > + Translation of android special user names is not done > > > > > > > > > > > > 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. > > > > > > > > > > > > Because I am not going beyond listed items, a patch can be > > > > > > developed just to support these inside musl-linked binaries. > > > > > > > > > > > > I am first here or there is already someone who done this > > > > > > before? > > > > > > > > > > I made a patch to implement all three things for musl on > > > > > android. > > > > > > > > > > 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/. > > > > > > > > > > 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. > > > > > > > > > > Patch is still in it's alpha stage, and probably will be changed > > > > > often. > > > > > > > > > > Modifications made for musl 1.1.4. > > > > > > > > > > If anyone interested to audit it - welcome! > > > > > > > > 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? > > > > > > 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(). > > > > 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. > > > > > > 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. > > > > > > First, android has /etc -> /system/etc in place, but, > > > unfortunately, no more :( > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > All this is based on my experience with some android devices I > > > working (and worked) with. > > > > 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... > > > > I'd really like to hear from the Android side what their motive is for > > breaking this by not providing the proper symlinks. > > > > 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. It would be very much appreciated to send patches as attachments rather than links. There's no way to have a well-documented ongoing discussion of the patch if it's not in a permanent place for review, and attached to the email/archives is the best way to achieve that. Rich