ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/11/2013 10:31 AM, Colin Watson wrote:
> On Thu, Jul 11, 2013 at 09:40:30AM -0500, Ted Gould wrote:
>> I hesitate to call these requirements, because I don't feel I the
>> authority to declare them that, but I wanted to write down my
>> understanding of things to give people a chance to object.  If no one
>> objects, I guess this is canon.
> 
> click-package.readthedocs.org has some of this (you reference the
> corresponding source).
> 
>> A click package can be identified with a reverse domain name that
>> represents the project: com.ubuntu.foo
> 
> Yes.
> 
>> 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.


>> Every click package will contain a manifest that is the root of
>> information about that package.  It is in JSON and called manifest.json.
> 
> Yes.
> 
>> A click package may have (and won't in v1) several applications
>> available from that package.  Each of those are defined in the manifest
>> with one being designated as "primary" for showing to the user
>> removal/installation graphics.
> 
> Yes.  (Note that the complexity arising from this of needing a composite
> app-id/application/version identifier also arises from having multiple
> parallel-installed versions; we could only avoid the composite
> identifier if we eliminated both requirements.)
> 
>> Each application in the package will be represented by a file that
>> conforms to the Freedesktop.org Desktop file format that contains
>> information on the icon and executable path.  The core difference being
>> that it'll have relative paths that aren't resolvable using standard XDG
>> directory definitions (they'll all be in the package).
> 
> Yes.
> 
>> Each application defined in the manifest will also have a security
>> definition in the manifest.
> 
> Yes.
> 
>> Upon installation of the package there will be a set of hooks run.
>> There are two types of hooks, system hooks and user hooks.  An example
>> of a system hook would be one that builds the apparmor profile and
>> installs it.  An example of a user hook would be one that takes the
>> desktop file template and puts it in ~/.local/share/applications with
>> paths that can be resolved to the user selected installed version of the
>> app.
> 
> This is plausible, but system vs. user hooks aren't fully defined yet.
> 
>> When I user installs an application version that was already installed
>> by another user, the user hooks will be run in that user's account.
> 
> Yes.
> 
>> All user and system hooks will provide a way to clean up the system/user
>> account on uninstall of the version.
> 
> I would like to make this as declarative as possible, along the lines of
> the efforts I've made in the current hooks spec to avoid being
> error-prone; I hope that it will amount to "remove the file pattern
> named in the hook, and run the named update program if applicable to
> catch up with any changes", but we'll see.  This should settle down this
> month once I have a chance to play with some real-world examples.
> 
>> The Click packaging system will maintain a reference count for which
>> user installed which version of a particular package.  It will also
>> garbage collect when no user has that version of the application
>> installed.
> 
> Yes.  (Current implementation, deliberately as simple as possible:
> /opt/click.ubuntu.com/.click/users/$user/$app_id is a link to the
> version of $app_id installed for $user.)
> 
>> The graphical installer will query the Click packaging system to
>> determine disk space cost of installing a new application or version.
>> For instance, if it's just an upgrade on a single user system space used
>> would be: sizeof(new) - sizeof(old).  But if there is another user that
>> has the same version it is: sizeof(new).  If it's upgrading to a version
>> already installed by another user and this user is the last user for the
>> selected version it is: -1 * sizeof(old).
> 
> I think you're first to lay it out so explicitly, but seems plausible.
> 
>> When the security hook runs it will create an AppArmor profile of the
>> name $(click package)_$(application)_$(version) that the application
>> should be confined with.
> 

That is correct-- it looks at the name and version from the toplevel manifest
and each key from the manifest['security']['profiles'] dictionary to create the
profile names for different desktop files. We may only ship support one desktop
file initially, but the apparmor click hook won't be limited by that going forward.

> 
>> The same pattern as above should be consider the "Application ID" for
>> all usage throughout the system.  Including identifying the application
>> to Mir/HUD/etc.
> 
This keeps us in sync and I agree it is the correct approach. It handles
namespacing will and keeps everything in sync between the different components
(apparmor profile name, apparmor profile filename, APP_ID, etc).

There is an interesting new requirement (to me anyway) that core applications
will be packaged as click and some will not be confined (eg, the terminal app).
While the hugely vast majority of apps will be confined (any unconfined apps
will require manual review and not be automatically accepted), the manifest file
needs to support this. One idea is:
 {
   "name": "com.ubuntu.developer.username.myapp",
   "version": "0.1",
   "maintainer": "Your Name <your.name@xxxxxxxxxxx>",
   "title": "My Cool App",
   "framework": "ubuntu-sdk-13.10",
   "security": {
     "unconfined": True,
     "profiles": {
       "myapp.desktop": { },
       "myapp-camera.desktop": { }
     }
   }
 }

In this manner, creating the desktop file for unconfined is the same as confined
(ie, you generate $(click package)_$(application)_$(version) the same way). The
drawback is that the manifest file has to be consulted every time the
application is launched to see whether or not it should switch to an apparmor
profile.

I think a better idea is do this for unconfined apps:
 {
   "name": "com.ubuntu.developer.username.myapp",
   "version": "0.1",
   "maintainer": "Your Name <your.name@xxxxxxxxxxx>",
   "title": "My Cool App",
   "framework": "ubuntu-sdk-13.10",
   "security": {
     "profiles": {
       "myapp.desktop": {
         "template": "unconfined"
       },
       "myapp-camera.desktop": {
         "template": "unconfined"
       }
     }
   }
 }

In other words, my team provides an unconfined template and everything else
stays exactly the same (ie, no special casing-- we generate a (permissive)
apparmor profile of the form of $(click package)_$(application)_$(version) and
the upstart job can 'apparmor switch' into it just as with confined apps).

I like this because it is consistent with our current implementation.

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

Attachment: signature.asc
Description: OpenPGP digital signature