Thanks for the update.
I'm using a cp_mac build from mid June and initially has the standard apps etc.
I then add my own stuff but the problem is really com.android.inputmethod.latin
and its dictionary.
After more digging it seems that CheckPolicy in ActivityManagerService.java
calls pm.checkPolicy with the app info for "com.android.inputmethod.latin",
however the destinationProvider is null, therefore ContentSecurityManager.java:
if (destinationProvider == null) {
return false;
}
This is because the dictionary pack is not yet loaded so the calling app gets
killed. With the patch it lets the provider load, then checks if valid or not.
The content_permissions.xml entries are not required for this because the
the app and dictionary pack are one (they never even get checked in the
unpatched version anyway due to destinationProvider == null = death).
Hope this helps
Richard
----- Original Message -----
From: rpcraig <[email protected]>
To: Richard Haines <[email protected]>
Cc: seandroid <[email protected]>
Sent: Monday, 15 July 2013, 15:59
Subject: Re: CP_MAC - Fix activity manager content provider permission check
Richard,
I'm finding the content authority
'com.android.inputmethod.latin.dictionarypack' to be part of the Gapp
LatinImeDictionaryPack.apk. I'm not seeing this app or content authority in
AOSP. Are you including any other non-AOSP apps in your build or am I missing
something. And, while
packages/inputmethods/LatinIME/java/src/com/android/inputmethod/latin/BinaryDictionary.java
seems to define the string "com.android.inputmethod.latin.dictionarypack", the
actual content provider is implemented in LatinImeDictionaryPack.apk (just
using apktool to dump the manifest and looking for the provider tag reveals
this). If this is all true, the best approach is to add a
content_permissions.xml under the device or vendor tree and UNION it in.
Bob
On 07/15/2013 06:46 AM, rpcraig wrote:
> On 07/14/2013 08:25 AM, Richard Haines wrote:
>> In the ActivityManagerService.java source there is the following comment:
>> // Is this the best spot for this? Should we specifically let the
>> // other tests below try first and then right before a return
>> // is made do we try to apply our checks? That approach might
>> // make sense becuase maybe that provider doesn't even exist.
>>
>> The author is correct in that this is not the correct place. This is because
>> apps like "com.android.inputmethod.latin" can never run as it needs to load a
>> dictionary CP as a part of its process. I've therefore added the checkPolicy
>> call to various return points in the process. It may be that the call should
>> be added to more places, however the patch works with my simple tests.
>
> The original checkPolicy() covers you're three new places already, so I'm not
> sure what you're actually gaining by removing the old check. The reason
> you're getting a denial is because there is presently no policy in place to
> deal with this specific provider; a minor oversight on our behalf as we
> probably didn't exercise all the apps. I think the correct course of action
> is to address the denial by just creating a new policy entry in
> content_permissions.xml. Maybe try something like the following; we'll
> probably have to create a more appropriate type in the future. Or, we could
> even try to add this specific provider to an already existing type stanza
> protected by a signature.
>
> <type name="com.android.inputmethod.latin.dictionarypack">
> <provider value="com.android.inputmethod.latin.dictionarypack"/>
> </type>
>
> <allow source="shared"
> destination="com.android.inputmethod.latin.dictionarypack"
> permission="use;rw"/>
>
>
> On a side note, did you have to create any new policy for this content
> provider after you moved the existing checkPolicy() hooks? If not, doesn't
> that seem a bit suspicious? I would expect one of your new hooks to throw a
> denial.
>
>> The attached patches:
>> frameworks/base/services/java/com/android/server/am/ActivityManager.java
>>
>> The main symptom is that the popup keyboards did not work when editing text
>> and is shown in the logs as:
>> D/ActivityManager( 336): Denied USE permission between caller=xxx and
>> content authority=com.android.inputmethod.latin.dictionarypack
>> Where caller=xxx is the pid of the com.android.inputmethod.latin app
>>
>> "com.android.inputmethod.latin.dictionarypack" is defined in:
>> packages/inputmethods/LatinIME/java/src/com/android/inputmethod/latin/BinaryDictionary.java
>>
>> String DICTIONARY_PACK_AUTHORITY =
>> "com.android.inputmethod.latin.dictionarypack";
>>
>> Richard
>
>
> -- This message was distributed to subscribers of the seandroid-list mailing
> list.
> If you no longer wish to subscribe, send mail to [email protected] with
> the words "unsubscribe seandroid-list" without quotes as the message.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
