<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 25, 2022 at 2:27 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/24/22 10:47, enh wrote:<br>
> i know a lot of people have _hoped_ to use it and looked at it over the years,<br>
> but i don't think it's fit for purpose? the problem (ironically, given your<br>
> complaint) is that it doesn't know _enough_ about the system. so it's racy and<br>
> init has to run around after it fixing up the stuff (like selinux labels) that<br>
> it _doesn't_ set. (iirc it didn't even do regular unix permissions right?) so if<br>
> init's got to do _some_ of the work, init may as well do _all_ of the work so<br>
> there's no window where you can see a "half-finished" node.<br>
> <br>
> (and back to new content...)<br>
> <br>
> for googlers <a href="https://issuetracker.google.com/233703650" rel="noreferrer" target="_blank">https://issuetracker.google.com/233703650</a><br>
> <<a href="https://issuetracker.google.com/233703650" rel="noreferrer" target="_blank">https://issuetracker.google.com/233703650</a>> is an interesting bug where you can<br>
> see a partner wanting to use devtmpfs and me, dvander's boss, and "the highest<br>
> up security guy who still writes code" all saying roughly this. (it seems like<br>
> none of us are certain, but we all think it was some combination of selinux<br>
> labels and unix permissions.)<br>
<br>
This may be dunning-kruger talking but a unix domain socket can pass a<br>
filehandle between processes, a filehandle can point to an unlinked node that<br>
later gets linked into the filesystem (people use the magic /proc/self/fd<br>
symlinks for this in userspace), and xattr calls can work on filehandles, so it<br>
_seems_ like a userspace process could do all sorts of crap to an inode before<br>
its dentry gets created without inventing much new infrastructure for it?<br>
<br>
That wouldn't help you with AppArmor, but I've never used AppArmor...<br>
<br>
> what i don't know is how much work devtmpfs would need for us to be able to use<br>
> it, or whether we could realistically get that upstreamed. i don't personally<br>
> remember anyone trying --- iirc everyone who's looked at this problem has just<br>
> judged it "too hard to even try".<br>
<br>
Hi. I'm the guy who wrote the initramfs documentation, created busyboox's mdev,<br>
and hounded Greg KH for MULTIPLE YEARS to provide a stable sysfs interface to<br>
distinguish block devices from char devices (ala<br>
<a href="https://lkml.iu.edu/hypermail/linux/kernel/0707.2/3042.html" rel="noreferrer" target="_blank">https://lkml.iu.edu/hypermail/linux/kernel/0707.2/3042.html</a> and<br>
<a href="https://landley.net/notes-2008.html#05-05-2008" rel="noreferrer" target="_blank">https://landley.net/notes-2008.html#05-05-2008</a> and even meeting Greg and Kay in<br>
person at Ottawa Linux Symposium and sitting down with them for 15 minutes to<br>
have them explain to me what they THOUGHT I should do. A bit like the time I sat<br>
down with the systemd maintainer and jotted down<br>
<a href="https://landley.net/systemd-notes.txt" rel="noreferrer" target="_blank">https://landley.net/systemd-notes.txt</a>)<br>
<br>
I wouldn't say devtmpfs was created to shut me up, but let's just say it was in<br>
the constellation of factors. I've been tracking it since before it existed. I<br>
am not intimidated by the problem space, I just don't know what all of Android's<br>
needs are and I'm not a natural selinux user.<br>
<br>
I'm also aware that at least 2/3 of your needs by weight are "backwards<br>
compatibility" at this point, but there comes a time when "staying on a.out<br>
instead of ELF" could maybe use some lubrication. (You laugh, but in the deeply<br>
embedded world of nommu systems the binflt executable format is a.out derived<br>
and fdpic is ELF derived, and getting people to migrate is STILL ONGOING THERE.<br>
We can paper it over with ELF -fPIE binaries but that has its own issues.)<br>
<br>
Ahem. Tangent.<br>
<br>
> which is a shame because, yeah, it does solve<br>
> _some_ problems. they're just not problems that _real_ android usage has, at the<br>
> cost of introducing ones that do matter to real users. (sorry, yochiang! the<br>
> fact that you even know what mount(1) means "you are not the user" :-) )<br>
Any ecosystem has layers. Or does McDonalds serving 70 million customers per day<br>
and the USA only having 0.7 cattle farms (yes, real numbers) mean McDonalds'<br>
"real" concern is the people sitting in its restaurants and nothing else matters?<br></blockquote><div><br></div><div>(sorry, hadn't noticed this until i saw the rant on your blog :-) )</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>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 :-)</div><div><br></div><div>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.</div><div><br></div><div>(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.)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br></blockquote><div><br></div></div></div>