The data directories can be found here: http://developer.ubuntu.com/publish/apps/security-policy-for-click-packages/ (see 'Runtime Environment' at the bottom of the page). That page does not cover scopes though-- probably best to review the apparmor policy in /usr/share/apparmor/easyprof/{templates,policy_groups}/*/* for writable areas.
Note, I acknowledge the bug but I think the counter argument is that users would be surprised to see their data deleted which is why we have the current functionality. Consider any application which contains 'precious' data that cannot be easily restored, such as pictures, recorded audio, recorded video, documents, etc, etc. If we were to do this properly, I think it should be configurable. One idea is to have a check box to delete associated user data that the app created.
There are other questions too: what happens with trust-store permissions, with online account information, and online account cached accesses? There is probably more to consider.
Finally, deleting user data is fraught with danger. The attached patch does drop privileges, but I think we need to be very careful that the directory to be deleted is actually the one that the package created/is using (ie, we need to guarantee that Environment.get_user_config_dir() is the same as what UAL/aa-exec-click is giving to the app at runtime). We need to be sure not to follow symlinks on the toplevel directory being deleted and for files inside the to be deleted directory, not to follow symlinks outside of the app's writable areas. We have application isolation in place to protect the user and the system from malicious applications, but the proposed click removal process is unconfined-- it would be a shame if a malicious app author decided to delete the user's files as part of its removal process.
In addition to defensive coding, we could in theory have a click user data remover helper which click would run under the apparmor profile of the app. This gets fairly complicated with click packages that ship multiple applications and hooks.
The data directories can be found here: http:// developer. ubuntu. com/publish/ apps/security- policy- for-click- packages/ (see 'Runtime Environment' at the bottom of the page). That page does not cover scopes though-- probably best to review the apparmor policy in /usr/share/ apparmor/ easyprof/ {templates, policy_ groups} /*/* for writable areas.
Note, I acknowledge the bug but I think the counter argument is that users would be surprised to see their data deleted which is why we have the current functionality. Consider any application which contains 'precious' data that cannot be easily restored, such as pictures, recorded audio, recorded video, documents, etc, etc. If we were to do this properly, I think it should be configurable. One idea is to have a check box to delete associated user data that the app created.
There are other questions too: what happens with trust-store permissions, with online account information, and online account cached accesses? There is probably more to consider.
Finally, deleting user data is fraught with danger. The attached patch does drop privileges, but I think we need to be very careful that the directory to be deleted is actually the one that the package created/is using (ie, we need to guarantee that Environment. get_user_ config_ dir() is the same as what UAL/aa-exec-click is giving to the app at runtime). We need to be sure not to follow symlinks on the toplevel directory being deleted and for files inside the to be deleted directory, not to follow symlinks outside of the app's writable areas. We have application isolation in place to protect the user and the system from malicious applications, but the proposed click removal process is unconfined-- it would be a shame if a malicious app author decided to delete the user's files as part of its removal process.
In addition to defensive coding, we could in theory have a click user data remover helper which click would run under the apparmor profile of the app. This gets fairly complicated with click packages that ship multiple applications and hooks.