[apparmor] [PATCH] update man page for recent mount rule additions
John Johansen
john.johansen at canonical.com
Wed Apr 11 18:07:59 UTC 2012
On 04/11/2012 10:56 AM, Jamie Strandboge wrote:
> On Wed, 2012-04-11 at 10:45 -0700, John Johansen wrote:
>> On 04/11/2012 10:35 AM, Steve Beattie wrote:
>>> On Wed, Apr 11, 2012 at 10:27:48AM -0700, John Johansen wrote:
>>>> On 04/11/2012 10:09 AM, Steve Beattie wrote:
>>>>> 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,
>>>>>
>>>> that is close to what I intended, I did it as
>>>> mount options=(ro,atime) /dev/foo,
>>>> mount options=ro /dev/foo,
>>>> mount options=atime /dev/foo,
>>>
>>> Wait, the mount options don't accumulate? So
>>>
>>> mount options=ro /dev/foo,
>>> mount options=atime /dev/foo,
>>>
>>> would allow
>>>
>>> mount -o ro /dev/foo /some/mnt/location/
>>>
>>> and
>>>
>>> mount -o atime /dev/foo /some/mnt/location/
>>>
>>> but would not allow
>>>
>>> mount -o ro,atime /dev/foo /some/mnt/location/
>>>
>>> ? This is seriously confusing.
>>>
>> How so? Within a single rule options set they do accumulate
>> mount options=ro /dev/foo,
>> mount options=atime /dev/foo,
>>
>> are separate rules
>> mount options in (ro,atime) /dev/foo,
>>
>> is a different rule and it is equivalent to the 3 rules
>> mount options=ro /dev/foo,
>> mount options=atime /dev/foo,
>> mount options=(ro,atime) /dev/foo,
>>
> Note that John is using equivalent rules where I was using matching
> mount commands (which might be confusing).
>
right, I wanted to avoid switching syntax
>> not saying we couldn't treat 'in' as a straight up list of single '=' options but
>> it always was a set to me.
>>
>> Also I haven't seen a reply to the other question. What shoule
>>
>> mount options=ro options=atime,
>>
>> mean? Should it be
>> mount options=(ro,atime)
>>
>> as currently implemented, or should we change it to mean
>> mount options=ro,
>> mount options=atime,
>
> I think this is what I like:
> options=foo options=bar is 'xor' and matches only:
> $ mount -o foo ...
> $ mount -o bar ...
>
So I think that counts as 3 votes to change that, and I agree that makes a lot
more sense.
> options=(foo,bar) is 'and' and matches only:
> $ mount -o foo,bar ...
>
yep
> options in (foo,bar) is 'or' and matches only:
> $ mount -o foo ...
> $ mount -o bar ...
> $ mount -o foo,bar ...
>
> The above makes sense to me. It hadn't occurred to me to express it in
> these terms, so maybe it would make sense to take another crack at the
> man page with this terminology. 'and' and 'xor' are currently
> implemented, with 'or' matching the above, but also pulling in the
> inverse and null set.
>
well the 'and' and 'or' behavior was intended as I was thinking in terms
of sets, but I have to admit I missed the 'xor' behavior and that is
why we got the wrong implementation
>
>
>
>
>
More information about the AppArmor
mailing list