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

[Rob Landley]

On 8/24/22 10:47, enh wrote:
> 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.
> 
> (and back to new content...)
> 
> for googlers https://issuetracker.google.com/233703650
> <https://issuetracker.google.com/233703650> is an interesting bug where you can
> see a partner wanting to use devtmpfs and me, dvander's boss, and "the highest
> up security guy who still writes code" all saying roughly this. (it seems like
> none of us are certain, but we all think it was some combination of selinux
> labels and unix permissions.)

This may be dunning-kruger talking but a unix domain socket can pass a
filehandle between processes, a filehandle can point to an unlinked node that
later gets linked into the filesystem (people use the magic /proc/self/fd
symlinks for this in userspace), and xattr calls can work on filehandles, so it
_seems_ like a userspace process could do all sorts of crap to an inode before
its dentry gets created without inventing much new infrastructure for it?

That wouldn't help you with AppArmor, but I've never used AppArmor...

> what i don't know is how much work devtmpfs would need for us to be able to use
> it, or whether we could realistically get that upstreamed. i don't personally
> remember anyone trying --- iirc everyone who's looked at this problem has just
> judged it "too hard to even try".

Hi. I'm the guy who wrote the initramfs documentation, created busyboox's mdev,
and hounded Greg KH for MULTIPLE YEARS to provide a stable sysfs interface to
distinguish block devices from char devices (ala
https://lkml.iu.edu/hypermail/linux/kernel/0707.2/3042.html and
https://landley.net/notes-2008.html#05-05-2008 and even meeting Greg and Kay in
person at Ottawa Linux Symposium and sitting down with them for 15 minutes to
have them explain to me what they THOUGHT I should do. A bit like the time I sat
down with the systemd maintainer and jotted down
https://landley.net/systemd-notes.txt)

I wouldn't say devtmpfs was created to shut me up, but let's just say it was in
the constellation of factors. I've been tracking it since before it existed. I
am not intimidated by the problem space, I just don't know what all of Android's
needs are and I'm not a natural selinux user.

I'm also aware that at least 2/3 of your needs by weight are "backwards
compatibility" at this point, but there comes a time when "staying on a.out
instead of ELF" could maybe use some lubrication. (You laugh, but in the deeply
embedded world of nommu systems the binflt executable format is a.out derived
and fdpic is ELF derived, and getting people to migrate is STILL ONGOING THERE.
We can paper it over with ELF -fPIE binaries but that has its own issues.)

Ahem. Tangent.

> which is a shame because, yeah, it does solve
> _some_ problems. they're just not problems that _real_ android usage has, at the
> cost of introducing ones that do matter to real users. (sorry, yochiang! the
> fact that you even know what mount(1) means "you are not the user" :-) )
Any ecosystem has layers. Or does McDonalds serving 70 million customers per day
and the USA only having 0.7 cattle farms (yes, real numbers) mean McDonalds'
"real" concern is the people sitting in its restaurants and nothing else matters?

Rob