[apparmor] create permission

[Jamie Strandboge]

On Fri, 2010-12-17 at 00:57 -0800, John Johansen wrote:
> On 12/16/2010 11:28 AM, Christian Boltz wrote:
> > Am Donnerstag, 16. Dezember 2010 schrieb John Johansen:
> >> So apparmor has had a create permission for a while now, but it has
> >> not been directly expressible in policy.  I would like to fix this
> >> however the letter c which is a natural fit for create (and is what
> >> is used by the kernel when reporting it) is used as an x modifier
> >> for children profiles (cx, Cx).
> >>
> >> So to expose the create permission we have a few possible choices.
> >> 1. choose a different letter
> > 
> > That would be my favorite solution.
> > 
> > What about "n" as in "new file" or uppercase "A" (similar to lowercase a 
> > for append)?
> > 
> > Not as obvious as c would be, but both variants still have a meaning.
> > 
This is my 2nd choice. For some reason, I like 'A'. 'n' is ok by me too.


> Seth just reminded me of another possibility which is slightly confusing,
> but might be cleaner in the long run.
> 
> Remove c from x, and replace it with something else (perhaps ^ as hats
> are just a variant of a child profile).
> 
> I think we can entertain this possibility for two reasons.
> 1. I don't think children profiles are in wide use, in fact I would be
>    surprised if anybody is using them.
Ubuntu uses cx, and so do I, personally.

> 2. We are going to be adding a version tag, and that provides an
>    opportunity to break a few things in a clean way

It isn't just the parser and the tools, it is the documentation and the
people using them. Granted, 'cx' has been under documented in our source
documentation, but I don't know what else is floating around out there
and if nothing else there is an existing profile in Ubuntu that uses
this and is on every Ubuntu Desktop since 9.10 (ie, over a year). IMHO,
we are too much committed. If we were discussing child profiles and
creat at the same time, I'd prefer 'c' for creat (but my first choice
even here is below), however that is not the case.


> >> 2. use c and either require it is either
> >>    2.1 not used immediately to the left of x if it is to mean cx.
> >>        ie. xc == create and execute
> >>            cx == child profile transition
> > 
> > I'm afraid that's more confusing than using a different letter.
> > (And I don't even want to know how "interesting" it would make vim 
> > syntax highlighting...)
> > 
> agreed that solution just sucks

Please don't do this (though I think we have consensus here :).

> >> 3. exposed through long for permissions, ie. using the create keyword
> >>    /foo create px,
> > 
> > No keywords for file permissions, please. That would be inconsistent 
> > syntax-wise (all other file permissions use letters).
> > 
> Actually I think that is almost unavoidable at this point, but that is
> because the actual set of permissions is much wider than is currently
> exposed.

This is my 1st choice. If we shift our thinking and reserve/enforce the
single letter permissions to only shorthands for mappings of two or more
longhand ones (eg 'w' for create, delete, trunc, write, meta-write,
chmod, chown, mmap_w, partial rename), then for create we just use
longhand for when we want to be more specific (I realize 'x' is special
here, but it is special in other ways too, so I don't mind it). This is
both consistent with current policy, documentation and current use. Put
more simply:

* Right now we really only have shorthand mappings. Continue to support
them in their present form and only add a new shorthand (ie single
letter) mapping for when it makes sense to group several permissions
into a new mapping
* Break out the longhand permissions in the priority of their utility,
and allow people to use them in combination with the shorthand mappings
for more fine-grained permissions. It sounds like 'create' may be the
first to be broken out in this way.

This seems to provide a clear path forward for adding finer-grained
permissions without breaking current conventions.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/apparmor/attachments/20101219/f9b514b7/attachment.pgp