[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jan 2015 17:34:03 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: musl and android
В 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.
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.
