Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ContentResolverFileAccessDeniedException with custom file provider #187

Open
marccala opened this issue Oct 6, 2023 · 8 comments
Open
Labels
Bug Under Investigation The issue is currently being investigated by the product team.

Comments

@marccala
Copy link

marccala commented Oct 6, 2023

Intune Android App SDK [Gradle Build Plugin] Issue

Questions to Ask Before Submission

  1. Does your app compile and launch successfully without the Intune App SDK? YES
  2. Have you checked the [Microsoft Intune App SDK for Android] repository for similar issues? It seems to be similar as: Reading application's own content Uri gets blocked when read data policy is enabled #160
  3. Are you using the latest version of the [SDK and Plugin]?

Summary

Dear Intune SDK support,

After contacting the Intune support I have been told to open an issue here.

We are currently facing an issue on Android with our custom file provider getting a ContentResolverFileAccessDeniedException.
This issue seems to be similar as: #160

Description of the issue:
Prerequisite: On Intune Portal, “Receive data from other apps” is set as “Policy managed apps”

Scenario: Display an image in our app with Picasso library

URI of the image: content://com.myapp.custom.fileprovider/attachments_cache/IMG20230920110632.jpg

Declaration in the Manifest of our CustomFileProvider, this class extends the Android FileProvider class

        <provider
	        android:name=".com.myapp.CustomFileProvider"
   		android:authorities=“com.myapp.custom.fileprovider"
    		android:exported="false"
    		android:grantUriPermissions="true”>
         </provider>

Call Stack

com.microsoft.intune.mam.client.content.ContentResolverFileAccessDeniedException
			at java.lang.reflect.Constructor.newInstance0(Native Method)
			at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
			at com.microsoft.intune.mam.InterProxy.CertificateInfo$1(:501)
			at com.microsoft.intune.mam.InterProxy.notify(:33)
			at com.microsoft.intune.mam.InterProxy$InterInvocationHandler.invoke(:87)
			at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
			at $Proxy28.openInputStream(Unknown Source)
			at com.microsoft.intune.mam.client.content.MAMContentResolverManagement.openInputStream(MAMContentResolverManagement.java:151) => 2. The call is intercepted by Intune
			at com.squareup.picasso.ContentStreamRequestHandler.getInputStream(ContentStreamRequestHandler.java:44) => 1. Here Picasso will ask Android framework which file provider it should use to open the file
			at com.squareup.picasso.ContentStreamRequestHandler.load(ContentStreamRequestHandler.java:39). 
			at com.squareup.picasso.BitmapHunter.hunt(BitmapHunter.java:206)
			at com.squareup.picasso.BitmapHunter.run(BitmapHunter.java:159)
			at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:487)
			at java.util.concurrent.FutureTask.run(FutureTask.java:264)
			at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
			at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
			at java.lang.Thread.run(Thread.java:1012)
			at com.squareup.picasso.Utils$PicassoThread.run(Utils.java:411)

Note

This issue doesn’t happen if we use Android FileProvider (androidx.core.content.FileProvider)

URI: content://com.myapp.fileprovider/attachments_cache/IMG20230920110632.jpg

Declaration in the Manifest of the custom file provider

        <provider
    		android:name="androidx.core.content.FileProvider"
    		android:authorities=“com.myapp.fileprovider"
    		android:exported="false"
    		android:grantUriPermissions="true”>
	</provider>

This issue also doesn’t happen with our CustomFileProvider if on Intune Portal “Receive data from other apps” is set as “All apps”

Details

  • Intune Android App SDK Version: 9.7.0
  • Gradle Version:8.0.2
  • AGP Version: 8.0.2
  • Operating System (Mac, Linux, Windows) and Version: MAC
  • Android Studio Version: Iguana

Logs

Incident ID: JQXJ7CZE

@Archit-Pikle
Copy link

Archit-Pikle commented Oct 11, 2023

Hi @marccala, can you share you app name where you're experiencing this issue?
In the powerlift ID, I only see logs for Edge, Outlook, Word and OneDrive.

Can you share logcat logs around the failure time?

@Archit-Pikle Archit-Pikle added the Need More Information Waiting for more information from issuer in order to resolve issue. label Oct 11, 2023
@marccala
Copy link
Author

Hi @Archit-Pikle

The app where I'm experiencing this issue is called Symphony. It's the second time that someone from Intune told me that in Intune log one cannot see the log from Symphony. Do you have any explanation about this fact?

I created a new Incident ID 23DF7T5C. In this incident I install the Symphony for Intune app from the Play Store, launch it and reproduce the failure. For security reason I will send the logcat log around this failure by email

Best regards,
Marc Calandro

@codylund
Copy link
Collaborator

Hi @marccala, it looks like the MAM logs for your app are still missing. It is not clear why this is the case. They should be available in your app's /cache directory in a folder named com.microsoft.intune.mam.log. Based on logs from the Company Portal, we are unable to locate any log files. The Company Portal is able to find logs for other MAM-enrolled apps on your device, so there seems to be something odd happening with your app. Is your application removing files in this location?

While we work through the logging issues, I can try to provide some context on the exception. In general, a ContentResolverFileAccessDeniedException indicates that the content identity (i.e. the identity of the file you are accessing via the provider) does not match the calling identity, and one of those identities has MAM policy that prohibits the read operation.

In your example, this means com.squareup.picasso.BitmapHunter.run() does not have permission to read IMG20230920110632.jpg due to one of the following (most likely #2 given that "Recieve data from other apps" is impacting the read operation):

  1. IMG20230920110632.jpg has been tagged with the managed identity, but com.squareup.picasso.BitmapHunter.run() is attempting to read the file as the empty/unmanaged identity.
  2. IMG20230920110632.jpg has been tagged with the empty/unmanaged identity, but com.squareup.picasso.BitmapHunter.run() is attempting to read the file as the managed identity.

As to why only com.myapp.custom.fileprovider is impacted, that may come down to implementation details. Are you able to share any context about how your custom FileProvider differs from the default AndroidX FileProvider?

@marccala
Copy link
Author

marccala commented Oct 26, 2023

Hi @codylund

I was able to get the MAM logs from the cache folder. I send them by email. As you suspected it seems that there is a problem with identity of the file, I can see with content identity <empty upn> or with content identity <null upn>

The Picasso library is charge of displaying images that are saved in the app cache directory. However these images are encrypted . When Picasso library try to open these images, our EncryptedFileProvider is called to decrypt them on the fly.
This EncryptedFileProvider extends AndroidX FileProvider and override public ParcelFileDescriptor openFile(@NonNull final Uri uri, @NonNull final String mode) and public final String getType(@NonNull final Uri uri).

If you cannot find the root cause of this issue we will consider making a sample application.

@codylund
Copy link
Collaborator

Thanks for the context, @marccala! If I'm understanding correctly, it sounds like the Picasso library is reading managed files (i.e. files tagged for the managed MAM identity) via your EncryptedFileProvider.openFile() implementation into an unmanaged context. MAM policy forbids this, so the read is getting blocked. We should be able to correct this behavior by ensuring the Picasso operations are running in the correct context for the file's identity.

To start, do you control the thread, Context, or process in which the Picasso library is loading the file? Ideally, you can correct the identity used by Picasso to match the file identity using one of the methods documented here: https://learn.microsoft.com/en-us/mem/intune/developer/app-sdk-android-phase5#setting-the-active-identity

If you are already setting the identity in the Picasso context correctly, we probably have a compatibility issue with Picasso. A sample app would be best, but we could start with a sample code snippet if your app's interaction with the Picasso library is simple enough.

@marccala
Copy link
Author

Hi @codylund

By adding in the manifest the support to multi-identity solves this issue.

 <meta-data
            android:name="com.microsoft.intune.mam.MAMMultiIdentity"
            android:value="true" />

The getProcessIdentity() returns null which I guess it's expected since I don't set the identity.

However my app is a single account app, only one account can use the app. For that reason I don't understand why I should set the multi-identity as true and why it solves this issue.
Why is it possible that Picasso library is reading managed files in an unmanaged context in a single identity application?

To reply to your question Picasso is loading the file from the applicationContext, I think it uses internally a thread pool and uses the application process.

@marccala
Copy link
Author

marccala commented Nov 7, 2023

Hi @codylund

Do you have any update on my question? Thanks

@bannus
Copy link
Collaborator

bannus commented Feb 14, 2024

We are investigating this issue, no timeline to share currently.

Intenal tracking #26168946

@bannus bannus added Bug Under Investigation The issue is currently being investigated by the product team. and removed Need More Information Waiting for more information from issuer in order to resolve issue. labels Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Under Investigation The issue is currently being investigated by the product team.
Projects
None yet
Development

No branches or pull requests

4 participants