A very neat option. I hadn't thought about tasks having policies on them. It does seem like a correct way to go, and a way that could help in some of the rootwrap area.
Good idea jay, the taskflow devs I think are starting to consider this idea and how it might be possible. There is as u said a long road, but I think this is just the way it goes, for better or worse. -Josh From: Jay Buffington <[email protected]<mailto:[email protected]>> Reply-To: OpenStack Development Mailing List <[email protected]<mailto:[email protected]>> Date: Tuesday, August 6, 2013 10:15 AM To: "Daniel P. Berrange" <[email protected]<mailto:[email protected]>>, OpenStack Development Mailing List <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] Python overhead for rootwrap 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
