Why was ro.control_privapp_permissions invented?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why was ro.control_privapp_permissions invented?

satur9nine
I read the article at https://source.android.com/devices/tech/config/perms-whitelist about ro.control_privapp_permissions and I understand how it works but I am left wonder why it exists? The docs say "device implementers had little control over which signature|privileged permissions could be granted to privileged apps". However they have plenty control, for apps they build themselves they can simply delete the permissions from the manifest. For apps which come from Google such as GMS it would seem futile for an OEM to decide they don't want to grant certain permissions, I'm sure Google wouldn't accept that. So what's the point? This lets OEMs include shoddy prebuilt apps into their system image and just give them a few permissions and hope they run properly?

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why was ro.control_privapp_permissions invented?

Colin Cross
From https://android.googlesource.com/platform/frameworks/base/+/d072d1415452abffd55a5742e3fef5abdaadf791, "Only devices with ro.control_privapp_permission=enforce will pass CTS tests.", so this is probably to ease the transition and bringup of new devices.  You can set your device to log, collect the missing permissions from logcat, add them to the whitelist, and then switch to enforce.

On Tue, Aug 7, 2018 at 2:01 PM satur9nine <[hidden email]> wrote:
I read the article at https://source.android.com/devices/tech/config/perms-whitelist about ro.control_privapp_permissions and I understand how it works but I am left wonder why it exists? The docs say "device implementers had little control over which signature|privileged permissions could be granted to privileged apps". However they have plenty control, for apps they build themselves they can simply delete the permissions from the manifest. For apps which come from Google such as GMS it would seem futile for an OEM to decide they don't want to grant certain permissions, I'm sure Google wouldn't accept that. So what's the point? This lets OEMs include shoddy prebuilt apps into their system image and just give them a few permissions and hope they run properly?

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why was ro.control_privapp_permissions invented?

satur9nine
I understand the "what" and the "how" of this feature but what I don't understand is the "why". Why was the existing permissions system not good enough that it needed this additional feature? The git commit message does not provide the answer to "why".

Jacob

On Tuesday, August 7, 2018 at 2:20:56 PM UTC-7, Colin Cross wrote:
From <a href="https://android.googlesource.com/platform/frameworks/base/+/d072d1415452abffd55a5742e3fef5abdaadf791" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://android.googlesource.com/platform/frameworks/base/+/d072d1415452abffd55a5742e3fef5abdaadf791&#39;;return true;" onclick="this.href=&#39;https://android.googlesource.com/platform/frameworks/base/+/d072d1415452abffd55a5742e3fef5abdaadf791&#39;;return true;">https://android.googlesource.com/platform/frameworks/base/+/d072d1415452abffd55a5742e3fef5abdaadf791, "Only devices with ro.control_privapp_permission=enforce will pass CTS tests.", so this is probably to ease the transition and bringup of new devices.  You can set your device to log, collect the missing permissions from logcat, add them to the whitelist, and then switch to enforce.

On Tue, Aug 7, 2018 at 2:01 PM satur9nine <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="nG7D3x8bDgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">satur...@...> wrote:
I read the article at <a href="https://source.android.com/devices/tech/config/perms-whitelist" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://source.android.com/devices/tech/config/perms-whitelist&#39;;return true;" onclick="this.href=&#39;https://source.android.com/devices/tech/config/perms-whitelist&#39;;return true;">https://source.android.com/devices/tech/config/perms-whitelist about ro.control_privapp_permissions and I understand how it works but I am left wonder why it exists? The docs say "device implementers had little control over which signature|privileged permissions could be granted to privileged apps". However they have plenty control, for apps they build themselves they can simply delete the permissions from the manifest. For apps which come from Google such as GMS it would seem futile for an OEM to decide they don't want to grant certain permissions, I'm sure Google wouldn't accept that. So what's the point? This lets OEMs include shoddy prebuilt apps into their system image and just give them a few permissions and hope they run properly?

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="nG7D3x8bDgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">android-platfo...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="nG7D3x8bDgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">android-...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/android-platform" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;">https://groups.google.com/group/android-platform.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.