MuntashirAkon
Use document provider to grant third-party apps access to app-private directories
With the introduction of File Manager where an elegant method has been developed to support opening any files from any directory via a content provider so that the recipient app does not require any file or root permission, it is possible to enhance this support via a document provider so that a third-party app can access app-specific private directories such as /data/data/package.name without root permission. This could greatly reduce the attack surface as fewer number of apps would need to use the root permission.
Possible use cases:
- Editing XML files at
/data/system/ifw/without granting root or even the editors that do not support root but support SAF (AKA document provider). - Granting file managers access to certain app directory, such as
/data/data/io.github.muntashirakon.AppManager/files/profilesso that you can add/edit profiles directly. - Backing up certain directory of interest via third-party event handling apps such as Tasker without letting them know about the location of the files and/or without granting root
- I forgot others, but the general idea is to minimise apps that can access root.
With the introduction of File Manager where an elegant method has been developed to support opening any files from any directory via a content provider so that the recipient app does not require any file or root permission
I'm a bit confused about "does not require file or root permission". Does it mean don't need root device or don't need grant root permission but still need root device?
I'm a bit confused about "does not require file or root permission". Does it mean don't need root device or don't need grant root permission but still need root device?
AM, of course, would require root permission. How else is AM going to access files and folders accessible only via root? The purpose is to minimise root usage by third-party apps in order to minimise attack surface, allowing the AM users handle app-private data with their favourite file manager or editor app without the need to grant root for the file manager. Document provider is perfect for this because it is an abstract file accessing mechanism (the core part of the Storage Access Framework) where the target app do not know the exact location of the file being processed.
AM, of course, would require root permission. How else is AM going to access files and folders accessible only via root? The purpose is to minimise root usage by third-party apps in order to minimise attack surface, allowing the AM users handle app-private data with their favourite file manager or editor app without the need to grant root for the file manager. Document provider is perfect for this because it is an abstract file accessing mechanism (the core part of the Storage Access Framework) where the target app do not know the exact location of the file being processed.
I see. Btw, maybe it will not very useful for most users but with adb mode users still can access "debuggable" third-party app-private data right? Can we use app_process run a service with that debuggable app permission to access its app-private data?
maybe it will not very useful for most users
Well, it mostly depends on my usage than the users. If I see something useful for me, I implement it in order to suite my need. Besides, many users are incapable of understanding the global picture of a feature unless it is implemented.
with adb mode users still can access "debuggable" third-party app-private data right?
Correct. The run-as command works for both root and ADB users.
Can we use app_process run a service with that debuggable app permission to access its app-private data?
I don't know what you've exactly meant here. But app_process doesn't work in the context of a user app, but if you take a look at the run-as source code, you'd see that it involves changing SELinux context to the target user app, effectively the same as su - <uid> in Magisk's su binary except that the former changes the working directory to the app-private directory before starting a shell environment. One solution could be to get this shell process in our remote service and use libsu's IO library for communication but the trouble is shell is notoriously slow, and for listing files we'd have to use the unreliable ls command.
One solution could be to get this shell process in our remote service and use libsu's IO library for communication but the trouble is shell is notoriously slow, and for listing files we'd have to use the unreliable ls command.
Is it possible to run a server/daemon(which implement file manager code) in this shell process with app_process and use IPC to access it function? I am sorry if it is stupid question because of my limited knowledge about this.
Is it possible to run a server/daemon(which implement file manager code) in this shell process with
app_processand use IPC to access it function?
No. As I've said above, app_process doesn't work for user apps.