[apparmor] create permission
john.johansen at canonical.com
Fri Dec 17 08:57:37 GMT 2010
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.
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.
2. We are going to be adding a version tag, and that provides an
opportunity to break a few things in a clean way
>> 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
>> 2.2 not used in a rule that has an x transition
> create and execute for the same file sounds scary (same for write +
> exec) - but that's a very good reason to make this possible. (The
> alternative would be *xw instead of *x+create, which would be more
>> 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
The letters are short hand and are what would be used commonly but it
would be good to expose some of the other functionality.
If your curious the larger permission set is
create - permission to create a file
delete - permission to delete a file
rename - a special rename permission that allows moving a file without
being able to read/write the file data.
read - permission to read a files contents
meta-read (attr-read???) - permissions to read a files meta data
write - permission to write data to a file, including extending the
file (implies append)
append - permission to append new data to the file (extending the file
size), no data overwrite. Must be used in conjunction with
application opening the file with O_APPEND, otherwise the
file open will fail.h
trunc - permission to truncate (shorten the file)
meta-write - permission to write a subset of the files meta-data not
controlled by specialized flags
chmod - permission to change DAC file permissions on the file
chown - permission to change file owner
link - permission to link to the file, when used with ** determines if
permissions apply to an entire subtree
lock - permission to lock a file, combines with append || write to
take exclusive lock
mmap_r - mmap a file readable
mmap_w - mmap a file writable
mmap_x - mmap a file executable
exec - permission to execute a file
with the current permissions mapping to
r - read, meta-read, mmap_r
w - create, delete, trunc, write, meta-write, chmod, chown, mmap_w,
partial rename (where it implies partial source rename permissions and
full destination renamed permission)
a - append, create
l - link (may be combined with other permissions to determine if allowed)
k - lock (combines with write to determine if exclusive lock is allowed)
m - mmap_x, mprot_wx
x - exec, (if ix then also mmap_x)
with x permission have the modifiers
More information about the AppArmor