[Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

[enh]

On Thu, Aug 25, 2022 at 1:05 AM Rob Landley <rob at landley.net> wrote:

> On 8/24/22 10:31, enh wrote:
> > On Wed, Aug 24, 2022 at 1:13 AM Rob Landley <rob at landley.net
> > <mailto:rob at landley.net>> wrote:
> >
> >     Applied the patch, but WOW this is conceptually ugly...
> >
> >     On 8/23/22 10:57, Yi-yo Chiang via Toybox wrote:> Android doesn't
> use devtmpfs.
> >
> >     Huh, I thought Android was using it because you guys got blamed for
> shoehorning
> >     userspace policy into the kernel back in 2013:
> >
> >     https://lwn.net/Articles/548477/#:~:text=devtmpfs
> >
> >     (The kernel having infrastructure to know that gid 44 is "video" and
> needing an
> >     /etc/groups that matches is kinda creepy. Yet another thing Kay
> Sievers
> >     advocated and Greg KH endorsed before Linus threw Kay out of kernel
> development
> >     and he went off to do systemd full time...)
> >
> >     Do you think Android is likely to start using devtmpfs at some point
> in the
> >     future?
> >
> > TL;DR: no, i don't.
> >
> > although i don't directly work on that stuff (and dvander is more likely
> to have
> > a canonical answer), i know a lot of people have _hoped_ to use it and
> looked at
> > it over the years, but i don't think it's fit for purpose? the problem
> > (ironically, given your complaint) is that it doesn't know _enough_
> about the
> > system. so it's racy and init has to run around after it fixing up the
> stuff
> > (like selinux labels) that it _doesn't_ set. (iirc it didn't even do
> regular
> > unix permissions right?) so if init's got to do _some_ of the work, init
> may as
> > well do _all_ of the work so there's no window where you can see a
> > "half-finished" node.
>
> Hence the 2013 article about putting policy into the kernel. In a terrible
> terrible way, brought to you by the systemd developers.
>
> What would have made SENSE was having the netlink hotplug interface (ala
> nlmsg_type = RTM_GETLINK) register to say it's going to send back response
> packets with credential info for each new node (something vaguely like
> nlmsghdr.nlmsg_flags = BLAH|NLM_F_SETCRED;) then having device node
> creation
> wait for the userspace credential request the same way it waits for a
> userspace
> firmware load request. You could even watchdog it where a timeout causes
> the
> device creation to return error and not make the node, and if the netlink
> program exits without properly deregistering (and a new instance doesn't
> restart) then that's gonna time out, meaning you can't do a security
> attack by
> trying to kill the daemon. (DOS sure, but show me a daemon kill that
> doesn't
> deny service.) And if you fire up the netlink daemon before mounting
> devtmpfs
> for the first time, it gets to annotate all the initial device node
> creations in
> a cleanish way so they're never exposed without credentials.
>

yeah, from what i remember, that's roughly what the people who actually
know what they're talking about said that they'd need. but that's also what
they thought they wouldn't be able to get upstream in any
realistically-spendable amount of time.


> (Making that work with different devtmpfs instances in different container
> levels calls for a whiteboard and multiple colors of markers, but probably
> isn't
> more than a two energy drink problem. The real questions there are all
> policy,
> not mechanism, and mostly boil down to me not having a CLUE how selinux
> interacts with namespaces. I assume the parent context is _providing_ the
> child
> context's hotplug events...? Do selinux rules nest? I'm pretty happy to
> not go
> there on a first pass..)
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220825/843f6d1f/attachment-0001.htm>