On Friday 25 October 2013 05:18:31 Jamie Strandboge wrote:
> On 10/24/2013 06:26 PM, Robert Schroll wrote:
> > Hi all,
> >
> > Since my previous questions about the content hub didn't get me anywhere,
> > I must have been asking stupid questions. Allow me to back up to a more
> > basic topic.
> I doubt that was the case-- probably simply that people got quite busy with
> 13.10's release.
>
> > This is the workflow I wish to enable:
> >
> > 1) The user copies (via rsync or Ubuntu One folder or whatever) files to
> > their home directory or subdirectory thereof of their device.
> >
> > 2) The user uses my app to display the contents of those files.
> >
> > 3) Optionally, my app can download more files of a similar type to the
> > same
> > location, so that the user can rsync (or whatever) these files back to
> > their computer.
> >
> > Is this possible with click apps in from the app store? If so, how?
>
> It is possible for files stored in the writable locations of your app. In
> practice, that means one of these directories (or a subdirectory):
>
> APP_PKGNAME="com.ubuntu.developer.username.foo"
> @{HOME}/.cache/@{APP_PKGNAME}/*
> @{HOME}/.local/share/@{APP_PKGNAME}/*
>
> Application confinement necessarily blocks access to arbitrary files in
> $HOME because of Ubuntu's trust model[1]. If your goal is to be able to
> sync arbitrary files in $HOME outside of the above app-specific directories
> across multiple devices, this is not currently supported and content-hub in
> its current form isn't going to be particularly helpful. Ie, right now,
> there isn't a 'file picking' content provider for your app to use with
> content-hub to prompt the user for a list of files. This will need to be
> supported for the converged device, but even when it becomes available,
> your app would only get a copy of the file in the app-specific directory
> but no way to sync the file back out to its original location (in the
> future, we should/may also support passing a file descriptor instead of a
> full copy-- but this is an implementation detail that won't help your use
> case). To support your use case, we need to somehow support persistent file
> access through content-hub or some other means (ie, allow the user to
> expand file access in a controlled manner). A very simplistic solution
> would be to expand content-hub to support hardlinking and then have your
> app use a (system) file picking content provider to choose which files to
> hardlink into place. This has a number of limitations (not least of which,
> security policy is not updated so it is difficult to know what files the
> app now has access to) but *may* be good enough depending on the
> implementation-- a more proper implementation requires apparmor user
> profiles, which is a desired feature but not something that is planned to
> be delivered for 14.04 or 14.10. Bottom line, this is an extremely security
> sensitive topic, difficult to get right and needs to be carefully
> implemented.
>
> In short, your use case falls into the category of 'backup software' and
> backup software is not supported by the appstore at this time.
Just to add some more unsupported use cases:
* A Music downloader
* An alternative Camera app that allows making funny pictures like the google
hangout toolbox
* An office suite
* An app like the Parrot AR.Drone controller wouldn't be able to store
pictures taken with the drone's camera in a place where a user can ever find it
again.
...
I personally think this should be considered higher priority than after 14.10.
Also I don't really see why allowing access to arbitrary subfolders in $HOME
(granted by policy ofc) is more problematic than allowing access to location,
address book, microphone or camera.
A policy "write_pictures" that gives write access to $HOME/Pictures doesn't
sound like the end of security to me.
Cheers,
Michael
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
