ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

On Fri, Oct 25, 2013 at 7:43 AM, Michael Zanetti <
michael.zanetti@xxxxxxxxxxxxx> wrote:

> 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.
>

That policy exists, it's called picture_files albeit it's a reserved
policy. Perhaps a different policy like  picture_files_append or
picture_files_add would be more lax?