Hey This is an extended reply to the thread that started here [1].
As I understand it, both Gustavo and Jamie recommend that if we fail to write any of the files in a directory we manage we should remove all of the managed files there because that is safer from security point of view (no partial security). For some back story, the EnsureDirState() function is meant to write four sets of files: /etc/udev/rules.d/ [subset] /etc/dbus-1/system.d [subset] /var/lib/snappy/apparmor/ [everything] /var/lib/snappy/seccomp/ [everything] Now imagine what happens if a particular write fails. I cannot give you a good reason why such a write would fail (except for a hardware fluke or running out of disk space). If one of the writes fail we'd remove all of the files managed in that directory. This would effectively cripple all the dbus services, all the device-passthroughs, all the apparmor and seccomp profiles. What I don't like about this is that failure in an isolated spot (installing a snap, connecting two snaps) has the side effect of breaking the whole system (as none of the apps would work anymore). If you follow the discussion there you can see that my recommendation is that we don't do this. On any write failure we bail out and let the caller decide. The caller still can decide to remove all the managed files so we don't lose that functionality. The advantage is that in the cases where we install new snaps or create new connections we can chose to remove only files related to the new content, thus not affecting other snaps that should work as before. Best regards ZK [1] https://github.com/ubuntu-core/snappy/pull/658#discussion_r56203587 -- snappy-devel mailing list snappy-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
