ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-07-12 08:25 AM, Jamie Strandboge wrote:
> 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?

I think we should be defining where these special case locations are, not
allowing _arbitrary_ special case locations. Special casing is more often than
not the wrong solution to the problem at hand.

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

They won't be able to if we don't support it with click packages. Giving them
permission to install click packages at arbitrary locations in the file system
is a bad idea.

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

The click package AppArmor hook could query the click package installer as to
where the installation path is. This would allow us to support custom locations
without embedding them in the manifest, which is controlled by the developer and
we can't change once the package ships. This also allows us to control what
those custom locations are.

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

I think this is beyond what is required. If the requirement is simply to have a
location to install preloaded click packages in the base image, and to have
pre-loaded click packages in /opt, adding one or two additional directories is
all that is required.

Colin, could you elaborate on what the exact requirement is?

Marc.