ubuntu-phone team mailing list archive

[Frans Schreuder <fransschreuder@xxxxxxxxx>]

Hello Jamie Strandboge,

Thanks for your reply

(...)
> This is a complicated topic and currently app-access to the SD card is not fully
> implemented. This has been discussed in the past and the main points are:
>
>  * we don't want to allow a shared storage area like <SD CARD>/freeforall
>    because that breaks application isolation
I totally agree here
>  * we could try to do something like:
>      owner <SD CARD>/<USER>/<PKGNAME>/** rwk
>    similar to the app-specific directories in /home, but that only works well
>    with Linux filesystems (eg, ext4) because some filesystems may not support
>    case-sensitivity, separate UIDs (for multiuser systems) or long filenames
This folder could be unreadable by the user, when connecting to the
computer. Especially when it is a hidden folder like the app storage in
home.
>  * Most things in Ubuntu Touch aren't aware of the SD CARD and the user
>    experiences have not been defined
>
> Because of this, only a couple of apps have special exceptions that grant them
> access to the filesystem.
>
>> Picture read could be possible, however it needs the maps
>> to be placed in <SD_CARD>/Pictures/osmscout. That is an ugly solution,
>> but it works.
> It does work in the sense that your app now has access to the folder, but it
> almost certainly doesn't work in the gallery, mediascanner, etc that have to
> deal with GBs of data that are in a subfolder that it scans for updates. Those
> apps would have to be updated to ignore the osmscout subfolder, which is even
> uglier.
I totally agree Pictures is not the way to go, this was the first folder
that I could get myself access to using simple rules.
>
>> Another solution is to set the app as unconfined, and use the location
>> <SD_CARD>/Maps/osmscout. However this is not the solution to allow for
>> any app, I think this app really adds value to the Ubuntu phone.
>> Would it be possible to create an app-specific rule that allows (Read,
>> and maybe later Write) access to <SD_CARD>/Maps/? Or otherwise to allow
>> this app to be published as unconfined?
>>
> There is no reason to run it unconfined when an app-specific directory could be
> used instead. As far as exceptions go, this is the cleanest solution because
> only your app would have access to this directory. Because of the
> case-insensitivity, you would need to do something like this:
>   read_path: [
>     "/media/*/*/[Mm][Aa][Pp][Ss]/"
>   ]
This is what I also did in the latest version that I uploaded (well, a
slightly different syntax but I will copy the line above) When I first
uploaded a version i was unaware of the possibilities of such custom rules.
>
> However, if you add that, what happens if the user has an Ubuntu Touch device
> that doesn't have an SD Card (eg, the reference Nexus 4)? AIUI, most new devices
> have a lot more storage and many are foregoing SD card support altogether.
For that reason I would also like to request access to another folder in
the home directory. e.g. $HOME/Documents/Maps. This way the app can
automatically check where maps are located, and let the user choose.
> Now, this doesn't deal with all the other problems with non-Linux filesystems on
> the SD CARD.
>
> I've included Thomas Voß in this email because he may have more information on
> the current status. Thomas (please forward if someone else knows),
>  * what is the current status of SD CARD access by apps, especially wrt
>    multiuser (UID mappings), case-insensitivity and short filenames? Is there a
>    roadmap?
For my app this wouldn't be a big problem, as long as I define the rule
as [Mm][Aa][Pp][Ss]
>  * is there a better way to handle map data? It seems like Frans is having to
>    deal with a lot of difficulties here with pregenerating map data and getting
>    it onto the SD Card. Are there plans for a maps service or something?
Well there isn't much of a problem, as long as the reviewer allows me to
create a rule dealing with read_path. OSMScout is using a custom binary
map format, which is converted from .osm xml using a simple application
based on libosmscout. I don't think these maps would be useful in any
way for applications that are not based on libosmscout.
>  * should we create a restricted 'maps' policy group that allows '~/Maps' and
>    '/media/.../Maps' like how the gallery current owns '~/Pictures'? The
>    question then is, who is the actual owner of Maps (ie, osmscout isn't like
>    gallery)?
I don't think a map policy would be necessary at this point, as the
read_path (and eventually write_path when downloading maps will be done
through the app)  does the job very well.

Thanks again for your input.

Frans
>

Attachment: signature.asc
Description: OpenPGP digital signature