Skip to content
Snippets Groups Projects
  • Jeff Sharkey's avatar
    6b75d099
    Let's reinvent storage, yet again! · 6b75d099
    Jeff Sharkey authored
    Now that we're treating storage as a runtime permission, we need to
    grant read/write access without killing the app.  This is really
    tricky, since we had been using GIDs for access control, and they're
    set in stone once Zygote drops privileges.
    
    The only thing left that can change dynamically is the filesystem
    itself, so let's do that.  This means changing the FUSE daemon to
    present itself as three different views:
    
    /mnt/runtime_default/foo - view for apps with no access
    /mnt/runtime_read/foo - view for apps with read access
    /mnt/runtime_write/foo - view for apps with write access
    
    There is still a single location for all the backing files, and
    filesystem permissions are derived the same way for each view, but
    the file modes are masked off differently for each mountpoint.
    
    During Zygote fork, it wires up the appropriate storage access into
    an isolated mount namespace based on the current app permissions.  When
    the app is granted permissions dynamically at runtime, the system
    asks vold to jump into the existing mount namespace and bind mount
    the newly granted access model into place.
    
    avc: denied { sys_chroot } for capability=18 scontext=u:r:vold:s0 tcontext=u:r:vold:s0 tclass=capability permissive=1
    avc: denied { mounton } for path="/storage" dev="tmpfs" ino=4155 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir permissive=1
    avc: denied { unmount } for scontext=u:r:zygote:s0 tcontext=u:object_r:tmpfs:s0 tclass=filesystem permissive=0
    
    Bug: 21858077
    Change-Id: Ie481d190c5e7a774fbf80fee6e39a980f382967e
    6b75d099
    History
    Let's reinvent storage, yet again!
    Jeff Sharkey authored
    Now that we're treating storage as a runtime permission, we need to
    grant read/write access without killing the app.  This is really
    tricky, since we had been using GIDs for access control, and they're
    set in stone once Zygote drops privileges.
    
    The only thing left that can change dynamically is the filesystem
    itself, so let's do that.  This means changing the FUSE daemon to
    present itself as three different views:
    
    /mnt/runtime_default/foo - view for apps with no access
    /mnt/runtime_read/foo - view for apps with read access
    /mnt/runtime_write/foo - view for apps with write access
    
    There is still a single location for all the backing files, and
    filesystem permissions are derived the same way for each view, but
    the file modes are masked off differently for each mountpoint.
    
    During Zygote fork, it wires up the appropriate storage access into
    an isolated mount namespace based on the current app permissions.  When
    the app is granted permissions dynamically at runtime, the system
    asks vold to jump into the existing mount namespace and bind mount
    the newly granted access model into place.
    
    avc: denied { sys_chroot } for capability=18 scontext=u:r:vold:s0 tcontext=u:r:vold:s0 tclass=capability permissive=1
    avc: denied { mounton } for path="/storage" dev="tmpfs" ino=4155 scontext=u:r:vold:s0 tcontext=u:object_r:storage_file:s0 tclass=dir permissive=1
    avc: denied { unmount } for scontext=u:r:zygote:s0 tcontext=u:object_r:tmpfs:s0 tclass=filesystem permissive=0
    
    Bug: 21858077
    Change-Id: Ie481d190c5e7a774fbf80fee6e39a980f382967e