[apparmor] DBus rule syntax for subject and peer components

[Steve Beattie]

On Thu, Jun 20, 2013 at 11:41:21AM -0700, Tyler Hicks wrote:
> Proposals that were decisively approved through voting:
> 
> * Proposal 3.1 - Change subj= to subject=
> * Proposal 3.2 - Move the access to the front

Yay. (Also, retroactive +1 from me on both.)

> Unfortunately, the way that I laid out the proposals in the last email
> did not result in clear decision on whether people preferred the
> original Proposal 3's grouping like subject=() or Proposal 3.5's
> subject {} style.

Really, seems like there's two orthogonal bits, whether to use '{}' or
'()' as delimiters and whether to have an '=' between subject/peer and
the delimiter.

I can see the argument against using '{}' as a delimiter due to
confusion with alternation uses (from a human cognition perspective,
not from a tool implementation perspective). So I lean towards using
'()' as the delimiter. But it's a not a strong preference.

As to using '=' prefixing the delimited group, I've grown comfortable
seeing it in the examples with it, but I don't have a strong
preference, so maybe +0.1? :)

>   # Talks to system and session buses
>   dbus (send receive) bus={system,session} peer=(name=org.freedesktop.DBus),

Shouldn't "(send receive)" be an alternation a la "{send, receive}"?
(Though it's an odd rule to begin with, stating that the screensaver
can both send to the org.freedesktop.DBus name and receive messages
sent to that name, assuming an acquire rule is also given to let it
acquire the name.)

On Thu, Jun 20, 2013 at 03:30:12PM -0700, Seth Arnold wrote:
> On Thu, Jun 20, 2013 at 11:41:21AM -0700, Tyler Hicks wrote:
> > * Revised Proposal 3 - subject=() and peer=()
> > 
> > dbus [acquire] [<bus>] [subject=(<subject>)],
> > dbus [send | receive] [<bus>] [subject=(<subject>)] [peer=(<peer>)],
> 
> 
> > * Revised Proposal 3.5 - subject {} and peer {}
> > 
> > dbus [acquire] [<bus>] [subject {<subject>}],
> > dbus [send | receive] [<bus>] [subject {<subject>}] [peer {<peer>}],
> 
> I slightly prefer 3.5 to 3 -- the = just feels like more noise to me.
> 
> Given that 3 looks like it is getting the consensus :) I'd like to cast
> a vote _against_ the following token definitions:
> 
> PEER		peer=(
> SUBJECT		subject=(
> 
> Those just seem wrong :) and I wanted to make sure that whatever is used
> allows whitespace to separate keywords and operators.

Yes, I agree. We've tried hard at the parser level to be fairly
whitespace agnostic to allow preferred organizational layouts.

For example, I would hope that the following layout would be accepted
under format 3:

  # Sends messages on the system bus
  dbus send   bus = system    peer = (
  	name=org.freedesktop.ConsoleKit
	path=/org/freedesktop/ConsoleKit/Manager
	interface=org.freedesktop.ConsoleKit.Manager
  ),

and format 3.5:

  # Sends messages on the system bus
  dbus send   bus = system    peer {
	name=org.freedesktop.ConsoleKit
	path=/org/freedesktop/ConsoleKit/Manager
	interface=org.freedesktop.ConsoleKit.Manager
  },

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130621/ab1b3eef/attachment.pgp>