[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150121183637.GK4574@brightrain.aerifal.cx>
Date: Wed, 21 Jan 2015 13:36:37 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl and android
On Wed, Jan 21, 2015 at 05:34:03PM +0700, Рысь wrote:
> В Sun, 18 Jan 2015 11:40:10 -0500
> Rich Felker <dalias@...c.org> пишет:
>
> > On Sun, Jan 18, 2015 at 03:01:19PM +0700, Рысь wrote:
> > > В Sun, 18 Jan 2015 01:44:40 -0500
> > > Rich Felker <dalias@...c.org> пишет:
> > >
> > > > On Sun, Jan 18, 2015 at 01:32:37PM +0700, Рысь wrote:
> > > > > В Thu, 15 Jan 2015 16:13:22 +0700
> > > > > Рысь <lynx@...server.ru> пишет:
> > > > >
> > > > > > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
