cacheSizeHint computation for webapps is incorrect due to apparmor denials

[Olivier Tilloy]

Since http://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/revision/1019, the webapp container (and all other embedders using an Ubuntu WebView) dynamically computes the cache size hint based on the available disk space.

This doesn’t work in the general case, when the app is confined by apparmor, because the computation relies on QStorageInfo::bytesAvailable() (http://doc.qt.io/qt-5/qstorageinfo.html#bytesAvailable), which triggers apparmor denials:

Jul 6 18:34:07 ubuntu-phablet kernel: [17458.604265]type=1400 audit(1436200447.375:184): apparmor="DENIED" operation="open" profile="com.ubuntu.developer.webapps.webapp-amazon-int_webapp-amazon_1.0.10" name="/proc/7424/mounts" pid=7424 comm="webapp-containe" requested_mask="r" denied_mask="r" fsuid=32011 ouid=32011
Jul 6 18:34:07 ubuntu-phablet kernel: [17458.604407]type=1400 audit(1436200447.375:185): apparmor="DENIED" operation="open" profile="com.ubuntu.developer.webapps.webapp-amazon-int_webapp-amazon_1.0.10" name="/dev/disk/by-label/" pid=7424 comm="webapp-containe" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0

This essentially means that the computation of the cache size hint is broken. It has also been reported that this breaks other apps’ functionality: https://lists.launchpad.net/ubuntu-phone/msg13622.html.

[Olivier Tilloy (osomon)]

Tentatively added an apparmor-easyprof-ubuntu task (although I’m not really sure what the way forward is to fix this bug).

[Seth Arnold (seth-arnold)]

I suspect this code ought to be amended to ask a service how much space is free for caching; users are liable to get cranky if they can't take more photos because a webapp cached a few gigabytes of cat gifs.

[Jamie Strandboge (jdstrand)]

I agree with Seth's suggestion, but for other reasons. We can't allow access to /proc/[0-9]*/mounts because it may contain sensitive information. Reading the directory contents of /dev/disk/by-label/ is likely ok (though there is also 'by-uuid' and 'by-id'). Can the calculation skip using /proc/[0-9]*/mounts and just use /dev/disk/by-label/? Ideally, the policy should not have to change at all and the app would talk to an out of process storage api (that is reasonable! :) to get this information.

[Olivier Tilloy (osomon)]

The implementation of QStorageInfo calls in to statvfs64, which tries to access /proc/<pid>/mounts and /dev/disk/by-label/, so there doesn’t seem to be a way around this without patching QStorageInfo. An out-of-process storage API would be ideal indeed. On whose plate would that fall?

[Jamie Strandboge (jdstrand)]

The storage API is being designed to handle SD card support for apps. You might talk to tvoss who is the architect for that.