> > > The core problem here is that I don't know which confinement profile
> belongs
> > > to what scope ID, so I don't know how to set the path correctly. If we
> have
> > a
> > > path that doesn't change depending on the confinement profile, the problem
> > > would go away because the prefix would be independent of the confinement
> > type.
> >
> > As mentioned, that breaks the confinement separation for the case when a
> scope
> > changes from leaf-fs to leaf-net. We need to have these scope type (eg,
> leaf-
> > net, leaf-fs) for whenever we confine both types. Putting it in
> > $HOME/.local/share/unity-scopes/<scope_id> or $HOME/.local/share/unity-
> > copes/data_home/<scope_id> breaks that.
> 
> Right, yes, this makes sense, thanks!
> 
> > Why not just add this to the scope runner .ini file:
> > [ScopeConfig]
> > Type=Network # or LocalContent or Aggregator
> 
> I think this approach has merit, at least to tidy us over until after RTM. I
> could make the setting optional, with the default being Type=Network. That
> means the setting would effectively be invisible to scope authors (though
> still documented), and only aggregators (us, mostly) would need to set it.
> 
> The path would be set accordingly, as "leaf-net" or "unconfined".
> 
> Directory creation can be done by the scoperunner, I think: if the directory
> doesn't exist, it'll be created on the fly.
> 
> > The downside is the scope author has to keep this in sync with the declared
> > template in the security manifest, but that is something the SDK can help
> with
> > (not to mention, people shouldn't be changing from one scope type to another
> > except in the most unusual circumstances).
> 
> Seeing that, at the moment, we have only two policies for scopes, I don't
> think that's a big deal. Longer term, once we have a fancier Apparmor query
> API, we should be able to ditch the config item again and just rely on what we
> learn from the query API. What I would like to have from the API is
> functionality that allows me to ask the question "what is the root of my
> writable data area?"
> 
> Ideally, I should get an answer even if that directory doesn't exist yet. And,
> if it doesn't exist, I should still be able to create that (and only that)
> directory. That way, the scoperunner wouldn't have to do anything on behalf of
> the scope before exec'ing it. Instead, the scope, after it was exec'd (and is
> confined already), could still create its own data directory if it doesn't
> exist.

The libapparmor query API won't be able to answer 'what is the base of my writable area'. It will be able to say 'can I write to $HOME/.local/share/unity-scopes/leaf-net/<scope_id>' or 'can I write to $HOME/.local/share/unity-scopes/leaf-fs/<scope_id>' so you can determine which is your writable area.

IMPORTANT: I think this is understood, the confined process will be able to create the '<scope id>' subdirectory (eg, $HOME/.local/share/unity-scopes/leaf-net/<scope_id>), so the scoperunner/API can do that. The confined process will *not* be able to create the 'scope type' directory (eg,  $HOME/.local/share/unity-scopes/leaf-net), which is why I said the scope click user hook could just make sure it exists.