[Apparmor-dev] mediating file locking

[Crispin Cowan]

Crispin Cowan wrote:
> Forwarding JJ's private mail:
>   
>> Currently apparmor does not mediate file locking.  It isn't a critical
>> problem but we should consider whether we want to and what the semantics
>> should be.
>>     
Good catch!

>> file locking can only be done on a file that has been opened so an
>> application can only access the files it has access to.
Good, so it is a lesser issue.

>>   What we
>> need to decide is if file locking should be limited to a
>> subset of current permission set and if so whether we should
>> distinguish between shared (read). locks and exlusive (potential
>> writer) locks.  I don't think we need to distinguish between advisory
>> and manditory locking.
>>
>> So we could:
>> - not mediate locking (current situation)
>> - map shared locks to read perm and exclusive locks to write perm
>>   - potentially widens access writes to a program that takes exclusive
>>     lock but only reads.
>> - mediate locking with extra permission or key word
>> - mediate locking right with extra perm/keyword and map lock type to
>>   r & w perms
>> - mediate different lock types each with their own permission or keyword
>>     
It strikes me as being similar to the extended list of operations you
can do to a file. We currently mediate r, w, Px, px, ix, ux, and l
(link). We have had requests for append, and now JJ makes the case for
locking.

It seems to me that we should round up a fairly exhaustive list of
extended file ops that we may want to mediate, and do them all at once.
It will cut down on the confusion and let us make rational choices as we
try to pick letters to map to each operation, e.g. locking doesn't get
'l' because that is taken :)

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com