[apparmor] [PATCH] update man page for recent mount rule additions

[John Johansen]

On 04/11/2012 10:26 AM, Jamie Strandboge wrote:
> On Wed, 2012-04-11 at 10:09 -0700, Steve Beattie wrote:
>> On Wed, Apr 11, 2012 at 09:56:58AM -0700, John Johansen wrote:
>>> So for the
>>>>> "When both = and in conditional operators are used the options within
>>>>> each condition type can be combined and split interchangeably."
>>>
>>> is for within a single rule
>>>
>>> that is to say
>>>
>>>   mount options=ro options=atime /dev/foo,
>>>
>>> is equivalent to
>>>   mount options=(ro, atime) /dev/foo,
>>>
>>> not
>>>   mount options=ro /dev/foo,
>>>   mount options=atime /dev/foo,
>>>
>>> though now thinking about it, this last interpretation might be better.
>>> It is not to late to change this, so I would like opions
>>
>> For the record, what I was hoping/exoecting the 'in' syntax would
>> accomplish was eliminating the need to write stuff like the latter;
>> i.e. that
>>
>>   mount options in (ro, atime) /dev/foo,
>>
>> would be equivalent to
>>
>>   mount options=ro /dev/foo,
>>   mount options=atime /dev/foo,
>>
>> and not
>>
>>   mount options=ro /dev/foo,
>>   mount options=rw /dev/foo,
>>   mount options=atime /dev/foo,
>>   mount options=noatime /dev/foo,
>>
> 'in' does more than that. Ie:
> 
> mount options=ro /dev/foo,
> mount options=atime /dev/foo,
> 
> Means these match:
> $ mount -o ro /dev/foo ...
> $ mount -o atime /dev/foo ...
> 
> But this doesn't:
> $ mount -o ro,atime /dev/foo
> 
> We can already do 'mount options=(ro,atime)'  which does the above. What
> makes 'in' useful is the combinations it affords:
> 
> mount options in (ro, atime) /dev/foo
> 
> matches:
> $ mount -o ro /dev/foo ...
> $ mount -o atime /dev/foo ...
> $ mount -o ro,atime /dev/foo ...
> 
right this is all good and I wouldn't change that

> It regrettably (due to kernel limitations) also lets the inverse options
> in there too (eg 'mount -o rw,noatime /dev/foo ...' also matches the
> above 'in' rule). It might be worth reconsidering if the null set should
> be allowed, which seems goofy to me.
> 
The null set was only allowed because of the weird implies negative options
stuff.  Fixing the implied negative also fixes the null set issue.

The implementation issue comes about due to how I was setting up the whole
matching for 'in', it was short sighted on my part and it does force us
to allow the implied options, but we can setup the matching differently
(entirely in the compiler, so no kernel changes needed), and things should
just work.

Sorry I didn't see it sooner

> Eg
> mount options in (ro, atime) /dev/foo
> 
> currently matches:
> $ mount -o /dev/foo ...
> 
> which does seem a bit odd. I'm ok with living with it in 12.04 if needed
> though.
> 
nah I would rather treat it as a bug and get it fixed

> 
> 
> 
> 
>