Discussion:
Valid range for stat userID and groupID?
(too old to reply)
darken
2017-05-13 13:29:17 UTC
Permalink
Raw Message
I stumbled upon the following "stat -c "%a:%F:%d:%i:%u:%g:%s:%B:%b:%Z:%N"
5665:FIFO (named
pipe):45836:456097:1171143868:4160815103:0:512:0:18446744073709551615:`/data/user/0/de.andip71.boeffla_config_v2/app_webview/webview_data.lock'

The a UID of "1171143868" and GUID of "4160815103" seems way too large. The
device in question is rooted and that specific file with sticky & suid bit
seems to be a bit special anyways, but I've also seen this from more
600:regular
file:100d:116024:1001:4294967295:16384:4096:32:1494489310:`/data/user/0/com.android.providers.telephony/opname.db'

GUID of "4294967295" seems large too.

Is it normal and I should expect these kind of values or is this some weird
root related stuff one should ignore or is it maybe a bug in toybox or the
Android kernel?

~Matthias
enh
2017-05-13 16:45:40 UTC
Permalink
Raw Message
are you building with bionic? glibc won't know what android does with
uid/gid for apps. (also, 4294967295 is -1.)

i couldn't find any files on a Pixel XL where the built-in toybox
reported unusual uids or gids.

as usual, not using Android's libc on an Android device is likely to
lead to confusing results.
Post by darken
I stumbled upon the following "stat -c "%a:%F:%d:%i:%u:%g:%s:%B:%b:%Z:%N"
5665:FIFO (named
pipe):45836:456097:1171143868:4160815103:0:512:0:18446744073709551615:`/data/user/0/de.andip71.boeffla_config_v2/app_webview/webview_data.lock'
The a UID of "1171143868" and GUID of "4160815103" seems way too large. The
device in question is rooted and that specific file with sticky & suid bit
seems to be a bit special anyways, but I've also seen this from more vanilla
600:regular
file:100d:116024:1001:4294967295:16384:4096:32:1494489310:`/data/user/0/com.android.providers.telephony/opname.db'
GUID of "4294967295" seems large too.
Is it normal and I should expect these kind of values or is this some weird
root related stuff one should ignore or is it maybe a bug in toybox or the
Android kernel?
~Matthias
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
darken
2017-05-13 17:00:44 UTC
Permalink
Raw Message
Post by enh
are you building with bionic? glibc won't know what android does with
I'm building against musl libc. I couldn't get toybox with bionic (though
the last time i tried was a few month ago).
Post by enh
glibc won't know what android does with uid/gid for apps.
Doesn't bionic/3rd party only make a difference when trying to resolve the
ids to names?
Post by enh
(also, 4294967295 is -1.)
Hm, -1 is not a valid guid though right? They all have to be positive
ranging from 0 to X?
Post by enh
i couldn't find any files on a Pixel XL where the built-in toybox
reported unusual uids or gids.

It's not very common, a few files, among a few devices out of thousands.
I never saw this in person either, just the occasional reports.
Post by enh
as usual, not using Android's libc on an Android device is likely to lead
to confusing results.

I'll look into setting up a bionic toolchain again.
You don't happen to have an edition of "Crosscompiling toybox with bionic
for dummies" at hand :)?
Post by enh
are you building with bionic? glibc won't know what android does with
uid/gid for apps. (also, 4294967295 is -1.)
i couldn't find any files on a Pixel XL where the built-in toybox
reported unusual uids or gids.
as usual, not using Android's libc on an Android device is likely to
lead to confusing results.
Post by darken
I stumbled upon the following "stat -c "%a:%F:%d:%i:%u:%g:%s:%B:%b:%
Z:%N"
Post by darken
5665:FIFO (named
18446744073709551615:`/data/user/0/de.andip71.boeffla_
config_v2/app_webview/webview_data.lock'
Post by darken
The a UID of "1171143868" and GUID of "4160815103" seems way too large.
The
Post by darken
device in question is rooted and that specific file with sticky & suid
bit
Post by darken
seems to be a bit special anyways, but I've also seen this from more
vanilla
Post by darken
600:regular
1494489310:`/data/user/0/com.android.providers.telephony/opname.db'
Post by darken
GUID of "4294967295" seems large too.
Is it normal and I should expect these kind of values or is this some
weird
Post by darken
root related stuff one should ignore or is it maybe a bug in toybox or
the
Post by darken
Android kernel?
~Matthias
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Rob Landley
2017-05-14 18:21:01 UTC
Permalink
Raw Message
Post by darken
Post by enh
are you building with bionic? glibc won't know what android does with
I'm building against musl libc.
which will try to read /etc/passwd and /etc/group which don't exist on
android.
Post by darken
I couldn't get toybox with bionic
(though the last time i tried was a few month ago).
I'm poking at the NDK, in theory that should build against bionic. In
practice, it's a work in progress:

http://lists.landley.net/pipermail/toybox-landley.net/2017-May/008976.html
Post by darken
Post by enh
glibc won't know what android does with uid/gid for apps.
Doesn't bionic/3rd party only make a difference when trying to resolve
the ids to names?
Post by enh
(also, 4294967295 is -1.)
Hm, -1 is not a valid guid though right? They all have to be positive
ranging from 0 to X?
They should, yes. (The two magic values to the kernel are 0 and 65534.
The second means "nobody" and there's actually some effort to make
multiple processes belonging to nobody not able to access each _other_.
See https://lwn.net/Articles/695478/ )
Post by darken
Post by enh
i couldn't find any files on a Pixel XL where the built-in toybox
reported unusual uids or gids.
It's not very common, a few files, among a few devices out of thousands.
I never saw this in person either, just the occasional reports.
Does it reliably happen on those files, or is it a race condition?
Post by darken
Post by enh
as usual, not using Android's libc on an Android device is likely to
lead to confusing results.
I'll look into setting up a bionic toolchain again.
You don't happen to have an edition of "Crosscompiling toybox with
bionic for dummies" at hand :)?
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.

Rob
darken
2017-05-14 19:16:31 UTC
Permalink
Raw Message
Post by Rob Landley
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?
Isn't reading uids/guids from inodes be independent from bionic/musl etc.?
On second thought, if this data is stored and read from the filesystem,
couldn't a filesystem corruption cause these values?
Post by Rob Landley
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.

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...
Post by Rob Landley
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 :)
Post by Rob Landley
Post by darken
Post by enh
are you building with bionic? glibc won't know what android does with
I'm building against musl libc.
which will try to read /etc/passwd and /etc/group which don't exist on
android.
Post by darken
I couldn't get toybox with bionic
(though the last time i tried was a few month ago).
I'm poking at the NDK, in theory that should build against bionic. In
http://lists.landley.net/pipermail/toybox-landley.net/2017-May/008976.html
Post by darken
Post by enh
glibc won't know what android does with uid/gid for apps.
Doesn't bionic/3rd party only make a difference when trying to resolve
the ids to names?
Post by enh
(also, 4294967295 is -1.)
Hm, -1 is not a valid guid though right? They all have to be positive
ranging from 0 to X?
They should, yes. (The two magic values to the kernel are 0 and 65534.
The second means "nobody" and there's actually some effort to make
multiple processes belonging to nobody not able to access each _other_.
See https://lwn.net/Articles/695478/ )
Post by darken
Post by enh
i couldn't find any files on a Pixel XL where the built-in toybox
reported unusual uids or gids.
It's not very common, a few files, among a few devices out of thousands.
I never saw this in person either, just the occasional reports.
Does it reliably happen on those files, or is it a race condition?
Post by darken
Post by enh
as usual, not using Android's libc on an Android device is likely to
lead to confusing results.
I'll look into setting up a bionic toolchain again.
You don't happen to have an edition of "Crosscompiling toybox with
bionic for dummies" at hand :)?
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.
Rob
Rob Landley
2017-05-14 19:54:32 UTC
Permalink
Raw Message
Post by darken
Post by Rob Landley
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
Post by darken
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.
Post by darken
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...)
Post by darken
Post by Rob Landley
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.
Post by darken
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.
Post by darken
Post by Rob Landley
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
darken
2017-05-14 20:26:20 UTC
Permalink
Raw Message
Post by Rob Landley
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.
Post by Rob Landley
Post by darken
Post by Rob Landley
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.)
https://github.com/landley/toybox/commit/3d64b0cc95c5
Post by darken
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.
Post by darken
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...)
Post by darken
Post by Rob Landley
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
else if (type == 'u') out('u', stat->st_uid);
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.
Post by darken
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.
Post by darken
Post by Rob Landley
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
Rob Landley
2017-05-13 17:38:37 UTC
Permalink
Raw Message
Post by darken
I stumbled upon the following "stat -c
5665:FIFO (named
pipe):45836:456097:1171143868:4160815103:0:512:0:18446744073709551615:`/data/user/0/de.andip71.boeffla_config_v2/app_webview/webview_data.lock'
The a UID of "1171143868" and GUID of "4160815103" seems way too large.
The device in question is rooted and that specific file with sticky &
suid bit seems to be a bit special anyways, but I've also seen this from
600:regular
file:100d:116024:1001:4294967295:16384:4096:32:1494489310:`/data/user/0/com.android.providers.telephony/opname.db'
GUID of "4294967295" seems large too.
That's -1 typecast to unsigned int.

Your previous UID and GID are:

1171143868: 0b01000101110011100011110010111100
4160815103: 0b11111000000000001111111111111111

Other than the first 8 bits of the first one being a capital "E" in
ascii this makes no sense to me.

Try running it under strace to see what stat() is returning?

Rob
darken
2017-05-13 18:09:51 UTC
Permalink
Raw Message
Unfortunately the output is from devices I don't have access to, via
automatic (anonymous) bug report.
Post by darken
Post by darken
I stumbled upon the following "stat -c
5665:FIFO (named
pipe):45836:456097:1171143868:4160815103:0:512:0:18446744073
709551615:`/data/user/0/de.andip71.boeffla_config_v2/app_
webview/webview_data.lock'
Post by darken
The a UID of "1171143868" and GUID of "4160815103" seems way too large.
The device in question is rooted and that specific file with sticky &
suid bit seems to be a bit special anyways, but I've also seen this from
600:regular
file:100d:116024:1001:4294967295:16384:4096:32:1494489310:`/
data/user/0/com.android.providers.telephony/opname.db'
Post by darken
GUID of "4294967295" seems large too.
That's -1 typecast to unsigned int.
1171143868: 0b01000101110011100011110010111100
4160815103: 0b11111000000000001111111111111111
Other than the first 8 bits of the first one being a capital "E" in
ascii this makes no sense to me.
Try running it under strace to see what stat() is returning?
Rob
Loading...