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

[enh]

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

> 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?
>

(sorry, hadn't noticed this until i saw the rant on your blog :-) )

to be clear: _my_ job is largely to support users like yochiang. that's
literally why i moved Android to toybox in the first place --- so that OS
developers like him (and, to a lesser extent since these tools are less
relevant to them/less useful in their restricted security context, app
developers) have everything they'd have if they were developing on linux or
macOS.

but "you are not the user" is a catchphrase we use that's meant to remind
us that we work on consumer products, and should always be asking ourselves
whether we're actually helping consumers.

to take your restaurant analogy, i think it's quite clear that, yes, a
restaurant should optimize for the people sitting in the restaurant. that
is literally their business. (and we have multiple restaurant options
available because even "people sitting in the restaurant" isn't one
homogenous group, and even the same person at different times might make
different restaurant choices. consumers who care more about farmers or
animals aren't eating at your fast food restaurant anyway.)

the code in init's job is to ensure various security properties which
devtmpfs as it stands is not capable of doing. so the question is "does
devtmpfs have advantages that would warrant the work of effectively
redesigning and reimplementing it in the upstream kernel, and then
switching the whole ecosystem over to using it?". and so far "it'd let us
remove an ugly two-line hack from toybox" is the only advantage i'm aware
of, so ... the cost/benefit analysis really isn't working out there :-)

the way to change that would be either reduce the cost (because upstream
ends up with something we can use, but that seems unlikely without us doing
a ton of work that no-one else would thank us for anyway) or increase the
benefit ... which brings us back to "you are not the user". i'm unable to
come up with any way in which devtmpfs would make consumers' lives better
(or even partners' lives), and given that opportunity cost is always
important, i can think of a ton of things those person-years could more
usefully be spent on.

(obviously this would be different if the costs of the status quo were
higher. but like i say, right now afaik that's basically just this one
hack.)


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220916/133bb514/attachment-0001.htm>