> Personally I'm of the opinion that from an architectural POV, use of > either rootwrap or sudo is a bad solution, so arguing about which is > better is really missing the bigger picture. In Linux, there has been > a move away from use of sudo or similar approaches, towards the idea > of having privileged separated services. So if you wanted todo stuff > related to storage, you'd have some small daemon running privilegd, > which exposed APIs over DBus, which the non-privileged thing would > call to make storage changes. Operations exposed by the service would > have access control configured via something like PolicyKit, and/or > SELinux/AppArmour. >
The more I think about this problem the more I'm convinced that rootwrap simply exists to work around a fundamental design flaw in most (all?) of the components: a single, threaded, process with poor job/workflow mnemonics. If the architecture was such that every operation was a task which could be carried out by any process (even a process running on a different host) and each process publishes job types that it can do, then you could do proper isolation for just those processes that need to do privileged tasks. https://wiki.openstack.org/wiki/TaskFlow looks to be headed in the right direction, but I worry it's got a very long road ahead.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
