Many things can happen while a private volume is ejected, so we need
to reconcile newly mounted volumes against known state.
First, user IDs can be recycled, so we store the serial number in the
extended attributes of the /data/user/[id] directory inode. Since a
serial number is always unique, we can quickly determine if a user
directory "10" really belongs to the current user "10". When we
detect a mismatched serial number, we destroy all data belonging to
that user. Gracefully handles upgrade case and assumes current serial
number is valid when none is defined.
Second, we destroy apps that we find no record of, either due to
uninstallation while the volume was unmounted, or reinstallation on
another volume.
When mounting a volume, ensure that data directories exist for all
current users. Similarly, create data directories on all mounted
volumes when creating a user. When forgetting a volume, gracefully
uninstall any apps that had been installed on that volume.
Bug: 20674082, 20275572
Change-Id: I4e3448837f7c03daf00d71681ebdc96e3d8b9cc9
Perform app op check in addition to the permisison check for all four
paltform components - activities, content providers, broadcast receivers,
services - if they are guarded by a permssion that has an associated app
op. This ensures that legacy apps will behave correctly if the permission
of the caller has been revoked, i.e. the app op for that permission was
disabled.
bug:22199666
Change-Id: Ia22d1c38d58b3cd6aabdc655cb7c7bddd85da7a2
...to an explicit toggle to enable in Settings
Add a new permission flag, saying the permission can be automatically
granted to pre-api-23 apps. Apply this to SYSTEM_ALERT_WINDOW.
Change-Id: I24a0ceabe7e9f5e458a864d30eda2696ad14a699
An intent may bounce several times between users.
In this case, we want mContentUserHint to refer to the original
user.
BUG:19656340
Change-Id: I22a35fab0c228140dcb223899f5e38ff33ee5aed
The default SMS, Phone, Browser are selected in the UI and we
grant default permissions to these. We do this regardless if
they are on the system image as the user has made an explicit
choice in the UI and the permission we grant are considered
essential for such type of a core app to operate properly.
bug:22104986
Change-Id: Ide8caeb524b43dde11a20460666cf34c4d35f84b
Currently registering for changes to a cross-user Uri does not work, as
the calling user id is used to identify the Uri. Change this to use the
userId the Uri is associated with. In order to protect Uris across
users, we only allow registration for a Uri when the caller has read
permission. We also only allow notify calls from across users when the
caller has write permission to the Uri.
Bug: 19312280
Change-Id: Ide216b09980ed5ebefe9b37c946dd8160167809f
That restriction applies only to default-app linkage verification, and
not to any general questions of "is this app effectively a web browser?"
Bug 21688029
Change-Id: I9f6a7bc6dcac5e12ee07f8da6465ad51c1aeddfb
The media provider and some other things need to be given storage access.
Also, seems like we should give storage access to the camera app as well.
And add a dump dump command that will dump data about a particular
permission name.
Change-Id: Idaaa9bba2ff4dc95290cf6d17e5df933df91e909
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: I62fb25d126dd815aea699b33d580e3afb90f8fd2
It is malformed to write a single intent filter like this:
<intent-filter android:autoVerify="true">
<data android:host="foo.example"
android:path="/"
android:scheme="http" />
<data android:host="*"
android:path="/custom"
android:scheme="fooexamplecustomscheme" />
</intent-filter>
In practice this app is accidentally defining a filter that will match
"http://*". This is now detected, and will never be auto-verified for
any of the mentioned domains.
Verified intent filters must *only* handle the http & https schemes.
Bug 21920537
Change-Id: I933cddbea23185d242565cac940e1e7a7e4e289b
Clarify docs that runtime permissions can be granted or revoked by
a profile owner/device owner only for MNC apps and not legacy apps.
Check the targetSdkVersion and return false if legacy app.
Remove all policy flags from permissions when cleaning up
a device or profile owner.
Bug: 21835304
Bug: 21889278
Change-Id: I4271394737990983449048d112a1830f9d0f2d78
Grant permissions in the PHONE and LOCATION buckets to default carrier
apps as defined by the telephony stack. Provide a system API to grant
default permissions for carrier apps, as the set of apps may change
when a new SIM is inserted.
Since the phone process is separate from the system process, we need
to allow for binder calls to these APIs.
Also fix a log tag that is too long (android.util.Log drops messages
silently if the tag is > 23 characters).
Bug: 21696731
Change-Id: I98ca0c49c69f621f835ba57c1fd0505f2cec0d0d
