If the user clears data for an app we reset the permission but
only the changes made by the user. We do not modify syste or
policy flags and also ensure the permission that were granted
by default are granted after the data wipe. This is the same
as starting with a clean slate.
If the package whose data is cleared is a part of a shared user
we resent to initial state only the permissions that the cleared
package contributed. Hence, if another package also declared the
permission as used we do not clear the permission state as it is
still in use.
When a package is deleted for a user but still present for another
user we reset its permissions to their inital state follwoing
above described strategy.
Lastly when a preinstalled package wtih an upgrade is diabled
(triggers upgrade uninstall) and this package is a part of a
shared user, we do not drop permission state (grants and flags)
for permissions used by the shadowed system package. This ensures
that we do not drop runtime permission state (such state is
default grants and user changes).i
bug:22248525
Change-Id: I3a3007476d2cb9f4ff824e1e137a6e1a4d04408b
This allows you to specify that a permission can be granted to
any pre-installed system app (not just privileged ones).
And as long as I am doing this, clean up the old "system" permission
flag, renaming it to "privileged" which is what it really is today,
deprecating the old names. And switch the platform's permission
declarations to use the new name.
Change-Id: Iabf484746af232144786851ec7fe90e3de9dddb2
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
