IssueTracker

My application offers 'suggested applications' that it can install and then use the functionality of, acting as a plug-in. Tasker is one of those.

My only work-around is to prompt the user to reinstall my application after the suggested applications have been installed, so permissions are detected.

It's of course a horrible 'solution'. Have starred the issue.

brandall

May be related: "protectionLevel=permission is not checked if other application is installed first and defines the same permission?" https://groups.google.com/group/android-security-discuss/browse_thread/thread/96cc19067c40fbf7.

Using the terminology from the original issue report, one workaround is for App A *and* App B to define the same <permission>. This gets a bit dicey in plugin situations, where App A is not written by the author of App B, only because App A would need all relevant resources (e.g., internationalized strings). OTOH, it works.

This has security implications as well. Consider the following:

---
App HOST allows access to personally-identifying information through a permission.
App PLUGIN can get access to this information by defining the <permission> as well, and using its own permission.
However, if HOST is not already installed, this permission is not shown to the user when PLUGIN is installed.
When HOST is later installed, PLUGIN now has access to HOST's data, even though the user was never aware of it.
---

Perhaps this is a separate bug. The expected behavior is, if an app has a <uses-permission>, that permission should be shown to the user REGARDLESS of whether the permission exists in another app or doesn't.

It doesn't work this way. Permissions are granted at install time *only*, so if you install HOST after PLUGIN, PLUGIN doesn't get any extra permissions. Of course, if they are using sharedUserId you get the union of both sets of permissions, but that's a different story.

Perhaps it's not meant to work this way, but I just tested and it does. I installed PLUGIN first (which has both <permission> and <uses-permission>), which obviously doesn't work correctly because HOST is not installed. Then I installed HOST (which has the same <permission> defined). PLUGIN now has access to HOST.

#9: However, you were presented with the custom permission at install time of PLUGIN, as you had <uses-permission>. The exception to this is signature-level permissions, which are never presented to the user, as the signature match alone is sufficient.

The problem here is that the PLUGIN can have a different description of the permission in its <permission> tag than the HOST.
You could even use descriptions that look like a boring android permission like INTERNET.

@mmurphy: That's the thing - at the time of PLUGIN's install, I did *not* see that permission. Could be my ROM though - running 4.2.2/SlimROM/Galaxy Nexus. Would be good if someone could confirm.

@domschuermann: But yes, different descriptions/icons/names are also a problem, and the solution to this isn't trivial.

Might I add, the permission level was kept at the default, and I signed the two packages with different signatures (one with a debug key, the other with a release).

Would anyone be able to confirm if the method I propose on this Stackoverflow post is 'secure' to use until this is resolved? If so, I'll copy the code to here.

http://stackoverflow.com/q/18573139/1256219

Thanks to #10 @@mmurphy for his comments on the above Stackoverflow post.

@Pent - Specific to your app, the work-around for me is to declare your custom permission in my manifest:

    <permission
        android:name="net.dinglisch.android.tasker.PERMISSION_RUN_TASKS"
        android:description="@string/tasker_description"
        android:label="Tasker"
        android:protectionLevel="normal" >
    </permission>

That way, if a user installs Tasker (app A) after my app (app B), the permissions are granted and avoids the user having to reinstall app B (http://stackoverflow.com/q/10620464/1256219), which of course is massive ball ache.

Declaring your/any custom permission to resolve this seems wrong in principle though. I tested declaring the above, without declaring:

     <uses-permission android:name="net.dinglisch.android.tasker.PERMISSION_RUN_TASKS" />

This did not work, which I assume is expected and a relief.

Until this issue is resolved, asking 3rd party developers to declare the same <permission> just doesn't feel right........ but I can't quite put my finger on why. I don't intend to do this and instead:

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first

private boolean checkPermissions(Context context, String callingPackage) {

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);

    for (PackageInfo pi : apps) {

        if (pi.packageName.equals(callingPackage)) {

            String[] permissions = pi.requestedPermissions;

            if (permissions != null) {
                for (String permission : permissions) {
                    if (permission.equals("com.package.a.permission.READ_APP_DATA")) {
                        return true;
                    }
                }
            }
        }
    }
    return false;
}

Now this issue has been assigned as a defect, I would urge the owner to get some feedback. I believe the Android permission system needs a radical overhaul as it is. With such a diverse set of users, the one-rule-fits-all can't continue - So getting this aspect right from the first fix would be a very good plan....

Over and out.

As of Android 5.1, at least, trying to re-define the permission gives an installation error for the second app:

W/PackageManager(  746): Package com.whatever.foo attempting to redeclare permission com.permission.your already owned by com.example.thing