diff options
author | Jeff Sharkey <jsharkey@android.com> | 2015-06-23 14:30:37 -0700 |
---|---|---|
committer | Jeff Sharkey <jsharkey@android.com> | 2015-06-25 22:27:04 -0700 |
commit | f38f29c87d97cea45d04b783bddbd969234b1030 (patch) | |
tree | baf822dc9522afff61ae4c8f412f5ba553b860ff /run-as | |
parent | 9a53bb0f809ae6d048646da2cf720d32d14f1a22 (diff) | |
download | core-f38f29c87d97cea45d04b783bddbd969234b1030.tar.gz core-f38f29c87d97cea45d04b783bddbd969234b1030.tar.bz2 core-f38f29c87d97cea45d04b783bddbd969234b1030.zip |
Let's reinvent storage, yet again!
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: I5a016f0958a92fd390c02b5ae159f8008bd4f4b7
Diffstat (limited to 'run-as')
0 files changed, 0 insertions, 0 deletions