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 > > > > > -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
