/var/tmp handling

[Jamie Strandboge]

I've seen the following denial in some java programs:

audit: type=1400 audit(1444152930.580:37): apparmor="DENIED" operation="open" profile="foo_bar_0.1" name="/var/tmp/" pid=1246 comm="java" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

The programs so far seem to function fine with the denial, but it seems like some app, somewhere, won't handle this well. Currently, we are recommending that apps use TMPDIR or SNAP_APP_DATA_PATH instead of /var/tmp. However, I wonder if it would be better to have the launcher handle /var/tmp in the same manner as /tmp by bind mounting the app-specific temporary directory as /var/tmp in the app's mount namespace. It is probably sufficient to simply bind mount the current app-specific temporary directory on both /tmp and /var/tmp in the app's mount namespace.

This changes the semantics of /var/tmp somewhat, since /tmp and /var/tmp for the app are handled identically, but I think this is probably fine and certainly better than the current situation of not allowing /var/tmp at all.