[guardian-dev] IOCipher multiple containers

[Hans-Christoph Steiner]

If your Services are indeed totally separate processes then the
unmounting shouldn't be needed really.  Unmounting is really only needed
to zero the password from memory.  A regular Android Service is not in a
separate process, you have to have `android:process=":service"` in the
<service> block in AndroidManifest.xml

.hc

zoki:
> I tried that (discussion above) but I have a problem:
> https://www.pastiebin.com/58b942a5c304b
> 
> - I start a service (in different process than app) where I create or mount
> an iocipher container. I'm playing files from it and when I'm done I detach
> all threads and unmount container (snippet below) and stop service
> (stopSelf; onDestroy on service is called).
> - When I start again I see that service is created again (onCreate in
> service is called) and I repeat a process same as before (iocipher
> container is mounted, reading from container for playing, when done detach
> all threads and unmount and stopService....)
> - After repeating that 4 or 5 times I get a crash (log is above)
> 
> I have more thread because I two schedulers.
> 
> I detach threads like this (there are always 3 or 4 active threads):
> 
> int i = 8;
> VirtualFileSystem vfs = VirtualFileSystem.get();
> while (i > 0 && vfs.isMounted()) {
>     try {
>         vfs.unmount();
>     } catch (IllegalStateException e) {
>         vfs.detachThread();
>     }
>     i--;
> }
> 
> Unmount on the end is always successful, but is this the correct way of
> unmounting container? Can be problem here?
> 
> For playback I'm using custom content provider (
> https://github.com/n8fr8/CameraCipher/blob/master/src/info/guardianproject/iocipher/camera/io/IOCipherContentProvider.java).
> Can be problem somewhere here that pipe is not closed? How could I check
> this?
> 
> I would be very glad if someone could point me to any direction where to
> check for errors why is this crashing. Thanks!
> 
> On Fri, Feb 10, 2017 at 12:21 PM zoki <zoran.smilevski at gmail.com> wrote:
> 
>> Thanks.
>> Service and provider in another process looks like a way to go. Will try
>> that.
>>
>> On Fri, 10 Feb 2017, 11:16 Hans-Christoph Steiner, <
>> hans at guardianproject.info> wrote:
>>
>>
>> hey Zoki,
>>
>> It is theoretically possible to use multiple containers, but it is not
>> well tested and it is not the use case we have in mind for it.  IOCipher
>> is designed around the idea of having a single file system that is
>> dedicated to the app.  It was not really designed to be general purpose
>> "containers".  That said, there is no technical limitation that would
>> prevent IOCipher from handling multiple containers.  Its mostly a
>> question of how to design a good API for that.  IOCipher uses
>> java.io.File as the API, there is no way to specify which container to
>> use in that API.  Having a global "switch container" method seems like a
>> recipe for many super confusing bugs.
>>
>> I think starting a Service in its own process for each container would
>> be the best way to do that with IOCipher as it is now.
>>
>> .hc
>>
>> zoki:
>>> Hello, I have few questions regarding using multiple iocipher containers.
>>> Is it possible to use multiple containers at the same time? Or at least
>>> easy switching between them?
>>> I don't know how to use them because VirtualFileSystem is singleton. I
>>> guess that has some purpose, can someone please explain why?
>>>
>>> Now with new ExoPlayer which has support for playing from content
>> provider
>>> is very easy to play videos from secure container. I'm thinking to use
>>> another container for caching video files, because it's easier to delete
>>> container files and free storage rather than doing container shrinking.
>>> Would I need to start new process for that?
>>>
>>> Thanks for any help :)
>>>
>>>
>>>
>>> _______________________________________________
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>>>
>>
>> --
>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
>> _______________________________________________
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>>
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556