ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-07-18 08:19 AM, Colin Watson wrote:
> On Thu, Jul 18, 2013 at 08:05:06AM -0400, Marc Deslauriers wrote:
>> On 13-07-17 12:55 PM, Colin Watson wrote:
>>> I like this layout a lot better: it actually makes some kind of sense to
>>> me, it's easier to read, and it repeats itself less.
>>
>> Except now we have to parse multiple json files and correlate the information we
>> need. For example, we find myapp.json. We now need to parse manifest.json to
>> figure out that myapp.json maps to the binary called "myapp", that the version
>> is "0.1", that the desktop file is "myapp.desktop", etc. It seems to me this is
>> overly complicated.
> 
> Maybe it just moves the complexity around; I assure you the complexity
> is at least as bad with the previous option, it's just not in your code.
> :-)

Hehe :)

OK, I've re-read your updated hooks spec, and I now understand why you prefer
having them in separate files. It makes sense to me too.

> 
> Not all the things you say here are true though; you should get the
> application name and version from the name of the symlink created by
> "click hook", as I discussed with Steve, not from the manifest.
> Furthermore, it is not clear to me why the AppArmor hook needs to know
> about the desktop file.

I was thinking we need to have a specific rule that includes the name of the
desktop file so an application can't read the other desktop files in the same
directory to enumerate installed applications. But, now that I think about it,
an application probably doesn't need to read its own desktop file, so I guess we
don't need to know what it is after all.

As you mentioned, we can always climb the directory in search of the main
manifest file if we need to.

> 
>> We also need a global security section somewhere, so we're going to need a
>> security section in manifest.json anyway.
> 
> Sure, as long as it's not part of a hook mechanism.  What will this
> section contain?

Nothing for now, as we have sane defaults. We had discussed having a global
section, but if the need arises, I guess we can simply duplicate the info in
each specific apparmor json file.

> 
>>> Furthermore, this
>>> way, click's hook execution can be almost entirely general: in this
>>> case, it would create symlinks in /some/apparmor/cache/directory/ named
>>> com.ubuntu.developer.username.myapp_myapp_0.1.json and
>>> com.ubuntu.developer.username.myapp_myapp-camera_0.1.json, each of which
>>> contains just the profile declaration for a single application, and
>>> something like click-apparmor can walk that directory for changes and
>>> generate and load profiles.
>>
>> I don't understand this part. What exactly is creating the symlinks?
> 
> "click hook".  See the Click hooks spec.

Ah! The spec evolved since my last reading of it, it makes sense to me now.
Sorry about that.

> 
>> Is this just for tracking which profiles have been generated already?
> 
> This is how you know which profiles are supposed to exist and where the
> apps in question are unpacked.  Otherwise we have to distribute
> knowledge of where apps live across various components, which is unwise
> given that we know of at least one way in which it's going to need to
> change.

OK

> 
>>> The one remaining non-generic thing here is as follows: my understanding
>>> is that for 13.10 the server is not going to have any facilities for
>>> scanning apps for problems and rejecting them.  This means that, IMO, we
>>> need to reject such things at the client end.  But that at least is a
>>> relatively small amount of code.
>>
>> We need to have a checklist which we manually go through when the app gets
>> uploaded. At some point, this will be automated.
> 
> Sure, but I thought we were all agreed that the more that was enforced
> and the less we needed to check, the better.
> 

I don't think we can reliably enforce a sane security policy on the client end,
but enforcing consistency makes sense, yes.

Marc.