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

[Rob Landley]

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.

(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