ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/11/2013 07:51 PM, Marc Deslauriers wrote:
> On 13-07-11 05:43 PM, Jamie Strandboge wrote:
>> On 07/11/2013 12:38 PM, Jamie Strandboge wrote:
>>> On 07/11/2013 10:31 AM, Colin Watson wrote:
>>>> On Thu, Jul 11, 2013 at 09:40:30AM -0500, Ted Gould wrote:
>>>>> A click package will have a version number defined, and will be
>>>>> installed in a separate directory based on the version number.  This
>>>>> directory will be /opt/click.ubuntu.com/$(package)/$(version)/
>>>>
>>>> You must not rely on this directory.  It may change, particularly to
>>>> support things like non-removable preinstalled apps in the system
>>>> partition, or other cases of OEM apps.
>>>>
>>>
>>> Not having a predictable location breaks application confinement. We necessarily
>>> need to know where apps are going to be installed. This can be solved by having
>>> different templates for the different install locations. It can also be solved
>>> by saying these apps don't use application confinement.
>>>
>>
>> Actually, we have some flexibility here because of aa-clicktool. The manifest
>> could specify "click_dir" (could be named anything) like so:
>>
> 
> We shouldn't put directories in the manifest file, as that will prevent us from
> changing click package locations in the future if we need to.
> 
I'm not sure why this would limit us more than we are currently limited. a) the
default location is not specified so there is no change over current behavior
and b) if the location is specified it is because it is a special case, and
changing the special case would need a new upload to change it anyway. Perhaps I
am missing something?

> Also, it adds even more complexity to the verification we need to do when
> packages get uploaded.
> 
This would require an additional check, yes.

> I'd really prefer having a couple of well-known install locations rather than
> making this dynamic.

I'm not sure we can predict this for OEMs and others working outside the
appstore and so adding other locations doesn't seem to help much, cause they may
choose to do something different beyond the ones we added. They may even choose
to run their apps unconfined (we have no control of these apps anyway).

If declaring the location or flagging to use a different location in the
toplevel manifest is unacceptable, the path needs to be given to apparmor
somehow. Assuming that installing and upgrading click packages in different
locations is solvable without declaring it in the manifest, we could approach
this in apparmor with:
 * keep adding paths to the Ubuntu templates as you suggest
 * have OEMs define their own templates/policy_groups
   in /usr/share/apparmor/{policy_groups,templates}/<oem>/<oem_version>, and
   then the security section of the click manifest would specify the template,
   policy_vendor and policy_version

I don't really like adjusting the paths in the Ubuntu templates unless we can be
sure to limit it to one other location (even this is not ideal to me, because it
opens the possibility that an app gets more access then intended if two
different apps with identical names are installed into different top level click
directories). To me, if they are choosing to install to another location, they
are choosing to work outside of the Ubuntu system, therefore they shouldn't
expect our Ubuntu templates to work, therefore doing a little extra work to
define their own templates and policy is acceptable (note, it doesn't have to be
a lot of work, they can symlink to our policy groups). This is in part what
policy_vendor and policy_version was designed for and provides them a lot of
flexibility.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature