> > B) Current toybox should, yes. Older ones had the API wrong: >
> https://github.com/landley/toybox/commit/3d64b0cc95c5 My toybox build is from April (https://github.com/d4rken/toybox/tree/sdmaid ). But if %u and %g is used I think it doesn't try lookup in /etc/ anyways, right? (...) > Which came from the kernel. That makes sense, so there isn't really anything to be done from this end. Should have looked more into the toybox code. Sorry for the false alarm and thanks for the insights guys! If I can ever reproduce this on a device I have access to, I'll open a ticket on the AOSP bugtracker. 2017-05-14 21:54 GMT+02:00 Rob Landley <r...@landley.net>: > > > On 05/14/2017 02:16 PM, darken wrote: > >> which will try to read /etc/passwd and /etc/group which don't exist on > > android. > > > > And then fall back to just use the numeric ids? Which are stored in the > > filesystem? Inodes I think? > > A) Some filsystems do. Fat won't. (The whole filesystem belongs to the > same user, you can set it at mount time.) > > B) Current toybox should, yes. Older ones had the API wrong: > > https://github.com/landley/toybox/commit/3d64b0cc95c5 > > > Isn't reading uids/guids from inodes be independent from bionic/musl > etc.? > > What's important is what the "stat" system call returns. How that's > implemented under the covers is hidden from userspace. > > > On second thought, if this data is stored and read from the filesystem, > > couldn't a filesystem corruption cause these values? > > Depends on the filesystem. How many of them store 32 bit uids? (ext2 did > this weird low 16 bits/high 16 bits straddle thing because the inode > format got extended over the years and they could only append, not > insert, so...) > > >> Does it reliably happen on those files, or is it a race condition? > > > > If there is such a file, it's read everytime like this. > > I don't think it's a new issue either, I just usually don't log this. > > Could have been the same with busybox. > > Whether it happens with busybox would be good to know, but I'm guessing > it does. We're reporting what's in stat: > > else if (type == 'u') out('u', stat->st_uid); > > Which came from either stat or lstat: > > if (flagf && !statfs(TT.file, (void *)&TT.stat)); > else if (flagf || (L ? stat : lstat)(TT.file, (void *)&TT.stat)) { > perror_msg("'%s'", TT.file); > continue; > } > > Which came from the kernel. > > > I've looked a bit more through the reports. > > 4294967295 is most common but there is also: 3912069456 or 3800903683 or > > 3780276225 or 3851690820 etc. but with those I can see that the user > > used some root tools to mount extra partitions (e.g. apps2sd -> > > /data/sdext2), so I would write those ones off as unrelated. > > > > 4294967295 accounts for 80% of the reports and 99% are from devices on > > Android 6.0.1, 93% of those are Samsung and mostly SM-N930F or SM-G900F. > > While I'm the first to chalk an issue up to a Samsung specific bug, this > > could also just be coincidence due to Samsungs device popularity... > > Usually -1 means "failure", although how that gets put into a stat > structure field I couldn't tell you. > > >> Send it to me if you find it. Bionic doesn't have a conventional > > makefile you can use to build it outside the AOSP hairball. > > > > Will do if I find one, first need to see about resizing my VM though if > > I want to download AOSP :) > > I plead the third. > > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
