[Feature] Allow mounting volumes with root

[Atrate]

A significant improvement would be to allow DroidFS to mount volumes under specified directories, such as /mnt/media_rw or in /storage using root permissions or a Magisk module.

[hardcore-sushi]

That's not the main goal of DroidFS. Mounting volumes would make them accessible by all apps with storage access, which is much less secure than opening volumes internally. However if you want this feature you can try the EDS app available on F-Droid.

[bingoxo]

EFS app

link to it please ? couldn't find it

[hardcore-sushi]

Sorry I mean EDS

[misterhsp]

EDS-lite on fdroid don't support gocryptfs an mount. mount only in the paid version on play-store

...

[hardcore-sushi]

Yes, that's why I decided to create a new app from scratch rather than contributing to EDS. In the future, I might add the "mount" feature but this is not the priority as I consider it insecure. (Of course, I accept your pull requests) Otherwise, have you an idea of how to deal with your problem in another way, without mounting the file system ?

[misterhsp]

Am 20.10.20 um 17:08 schrieb Hardcore Sushi:

Yes, that's why I decided to create a new app from scratch rather than contributing to EDS. In the future, I might add the "mount" feature but this is not the priority as I consider it insecure. (Of course, I accept your pull requests) Otherwise, have you an idea of how to deal with your problem in another way, without mounting the file system ?

No idea, mount is mount.

...

[hardcore-sushi]

Yes but what you exactly want to do by mouting the volume ? It might be possible to do it without mounting, by another way like Android intents or whatever.

[locuturus]

I suggest using a content provider. EDS lite does this (albeit poorly). Only apps which have been granted specific access to this hypothetical SAF-based DroidFS content provider (permission is granted via the Android document picker) can access the files inside.

[hardcore-sushi]

DroidFS already do that with the unsafe feature "Open files with other apps". However it only allows one file to be opened at time when the volume is opened. Allowing other apps to access files inside volumes means these files have to be decrypted and stored on disk for a possibly unlimited amount of time. This would be a big security issue. I don't know if I should implement this feature.

[locuturus]

I believe EDS decrypts on the fly, in RAM, when using the content provider. It uses pipes to provide the decrypted file content rather than creating an on-disk cache so far as I have been able to gather. Of course, using a 3rd party viewer can be unsafe for the usual reasons but as long as that viewer doesn't write it's own cache to disk the whole pipeline should remain in RAM if I've got that right.

Have you tried using it to see how it operates? Its content provider works pretty well with DocumentsUI, Material Files, and File Manager by axet. But development has apparently(?) stalled out and the only incremental cloud friendly format it supports is encfs which isn't super great...

[CodeCracker-oss]

@locuturus From my understanding EDS doesn't do on-the-fly encryption like desktop veracrypt or luks, because of technical limitations on android. I've used it on a rooted pixel 2 before when in active development and when I copied/moved files to container and the app had crashed, device reboot...all content copied/moved to it was lost, it seemed to only save the data when I specify manually to close it. This is something that doesnt occur with veracrypt because everything is done on-the-fly. EDS somewhat good but has many technical limitations because of android, even on a rooted device.

[hardcore-sushi]

I already tried to use a virtual file provider which store files only in RAM for DroidFS. The problem is that the client app could try to stat() this file but this call will fail if the file doesn't correspond to a real file stored on disk. The Android system (before Marshmallow) do that when playing media files. For example, if you open an audio file stored in memory with a basic music player (which use the standard Android API), the player app won't be able to play the file and can even crash if it doesn't handle the exception correctly. This is why I chose to first export files to disk before sending the Intent for the unsafe feature "Open with other apps".

[locuturus]

@dhammel if EDS isn't doing on the fly encryption then it's doing a pretty good job fooling me. I just ran a test, see what you make of it (apologies for length):

1. Change the temporary data path in EDS settings to somewhere you can observe and park a file browser there to see what goes on.
2. Create an empty encfs container, and give e.g. Material Files access to the content provider.
3. Park another file browser at the location of the at rest encfs files to observe the creation of encrypted files.
4. Move a batch of files, using DocumentsUI or Material Files, into the content provider and observe the at rest folder progressively gains encrypted files, and at no point during this transfer does any file appear in the temp data path. This all appears to occur in real time. Note that an app crash during transfer would perhaps lose data. I observe that SAF transfers blindly trust the destination so if EDS crashed then your file browser of choice may continue to send files into the non-existent content provider and delete the originals if performing a move. Classic Google right there. This scenario happened to me the other day using paragon to 'mount' a USB drive my Pixel doesn't support. It was taking too long and I was low on battery so I unmounted from paragon and the remaining queued files rapidly 'transferred' into the empty paragon container and were lost.
5. Open / view those files from the content provider. A Pixel's DocumentsUI viewer doesn't like them (EDS author once told me it might be a pipe issue but didn't look very far into it) but Material Files can view images quite well with the built in viewer. Observe no file appears in the temp data path. Nor does any appear when starting to share a file. This may or may not hold for all viewers or all file sizes/types. The settings imply this temp data path is used for something but exactly why and when isn't said aside from implying file writes might make use of it.
6. Now close the EDS container and enable Force temp files in settings. And repeat the above steps. Observe now that viewing images with Material Files does create temp decrypted files in the path you chose before. So does moving files into the container with DocumentsUI. Probably other actions as well.

@hardcore-sushi I think you are correct that some apps will fail. In the case of EDS, VLC player will not play anything. It throws a location file:///null error every time. But plenty of apps are compatible, and just wondering out loud here but shouldn't a SAF-aware app get used to the idea that files are abstractions on Android?

[hardcore-sushi]

Yes, importing files on-the-fly is relatively easy. DroidFS does that. The harder thing is to export on the fly because of the stat() calls. So I don't know if the file provider feature should be implemented with on-the-fly decryption or by writing files on disk.

[locuturus]

My 2cents is to default to on the fly, realizing some apps will be incompatible, and add an option, carefully labeled as unsafe, for caching to support picky apps.

[CodeCracker-oss]

@locuturus Some people think differently when hearing the term on the fly for one Technically EDS does do on the fly encryption, but not in a way most would be used to. Like using a file browser to copy data into this mounted device, then device crash for some reason and data is lost, that unacceptable but caused due to technical limitation on android with mounting virtual devices. There are numerous bugs that are present and more coming all the time, because of such limitations. I was in touch with developer helping him find and fix em', he did a great job at it, but still a pain to deal with.

Final result is, need to close container manually in EDS to 'save' the data copied to it, otherwise its gone forever, at least last time i used it on a rooted pixel 2. This isn't a way I ever known similar software to work, such as veracrypt, luks, encfs, gocryptfs, securefs, cryfs...

For real security, one shouldnt be using android to begin with, mobile os's suck in comparison to desktop os's.

[locuturus]

@dhammel I observe that new bulk file data really is present in the at-rest folder (in the case of encfs – I have little experience with the other containers) just as quickly as the EDS service can process them. Now, I don't know that EDS updates the xml file immediately, maybe that happens when the container is closed?

[hardcore-sushi]

I don't think data-loss will be a problem with DroidFS since all files are closed (therefore synced) right after their import.

So if the feature is implemented in DroidFS, it would require the unsafe feature "keep volume open in background" be enabled. An additional switch could be added like "provide opened volumes to other apps". When enabled, this switch shows a popup which asks if we want to use on-the-fly or on-disk decryption. Then, the corresponding content provider will be enabled.

I don't have so much time to code this right now so your pull-requests are very welcome !

[watson1423]

I had one similar need for mounting ftp samba or WebDAV I have a personally server with game roms and I would like to have my 300Gig of roms on my phone. Of course that is not possible with a 124Gig phone nor it would be convenient. I user RetroArch and searched for that a loot the only way is with termix rmount and that is not so easy to do. If any app allowed that in a "secure way for read only data" it would get massive attention from fans of emulation.