[apparmor] [PATCH 2/2 v3] tests: Add regression tests for dbus

[Tyler Hicks]

On 2013-08-13 22:13:55, Tyler Hicks wrote:
> Integrate dbus tests into the regression testing framework.
> 
> This started out as dbus-send.c, from the dbus source, and then grew
> from there.
> 
> dbus_message is an example "client" program that only sends out
> messages. dbus_service binds to a well-known name and then listens and
> responds to incoming messages. They share some code in dbus_common.c.
> 
> The test scripts, dbus_message.sh and dbus_service.sh, share some
> functionality in dbus.inc.
> 
> Signed-off-by: Tyler Hicks <tyhicks at canonical.com>
> ---
> 
> * Changes in v3:
>   - Add <apparmor mode="required"/> to dbus.conf to ensure that dbus-daemon
>     will either enforce AppArmor mediation or fail to run if AppArmor D-Bus
>     mediation is not available
>   - Do a best effort attempt to detect if dbus-daemon initialization was
>     successful in dbus.inc:start_bus(). A sleep and kill -0 isn't ideal, but
>     dbus-daemon forks before initialization is complete.
>   - Fix fatalerror message in dbus.inc:send() so that it correctly prints the
>     message type (thanks for pointing this out, Seth!)
>   - Unify error paths in dbus_service.c:main()
>   - Introduce an unlock_fd() function that is called from
>     dbus_service.c:main()'s error path. This makes sure that the fd that was
>     pre-locked by dbus_service.sh is always unlocked.
>   - Set up signal handling a earlier in dbus_service.c:main()
>   - Stop using runchecktest() in dbus_service.sh. Instead, wrap
>     service_runtestbg() and service_checktestbg() with service_runchecktest()
>     and use that in the two remaining runchecktest() call sites. This, along
>     with the unlock_fd() change and <apparmor mode="required"/> changes above,
>     fixes a hang that Jamie was seeing.
>   - Run dbus_{message,service,common}.c through the kernel's scripts/Lindent
>     script to make the coding style less like D-Bus and more like AppArmor.
>     Those source files only vaguely resemble D-Bus' dbus_send.c now, so there's
>     little value in sticking with the D-Bus coding style.
> 
> That last bullet point obviously makes it difficult to diff v2 and v3. If it
> would be helpful to see an incremental diff between v2 and v3, before I ran the
> .c files through Lindent, I can easily send it out. Just let me know.
> 
> Seth gave v2 an ack, but v3 changes enough that I didn't feel comfortable
> carrying that ack over. John gave v1 a tentative ack and I plan on waiting for
> a solid ack from him on v3 before committing it to trunk.

I'm sure that JJ hasn't had a chance to take a closer look like he had
wanted to, but I did address his feedback from his v1 review. Also, Seth
gave me an ack for v3. I think it is best to go ahead and commit v3 to
trunk at this point.

JJ - if you do get a chance to look at these tests and have improvements
that you'd like to see, I'll obviously be more than happy to make those
changes.

There are some more D-Bus tests that I plan on adding before 3.0 is
released, but this is a really good start that exercises the core
functionality of D-Bus mediation.

Tyler
-------------- 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/20130820/524c20c9/attachment.pgp>