Robert Collins wrote: > On 2 August 2013 20:05, Thierry Carrez <thie...@openstack.org> wrote: > >> It was a bit of a maintenance nightmare (the file was maintained in >> every distribution rather than centrally in openstack). Another issue >> was that we shipped the same sudoers for every combination of nodes, >> allowing for example nova-api to run stuff as root it should never be >> allowed to run. See [1] for the limitations of using sudo which >> triggered another solution in the first place. > > There's still nothing other than handwaving suggesting that a domain > specific solution is needed. setuid binaries *should* be rare, and > sudo's goal : policy driven sudo access - is totally compatible with > all our needs.
Are you familiar with rootwrap ? It is not setuid itself, and it's built *on top of sudo* and acts as an additional filter. It's not really a domain-specific solution, it just implements the missing functionality in sudo in a way that lets us avoid distribution and testing nightmares. One key benefit of rootwrap is that it lets us work with a defined and simple sudoers line, and then ship the rules within the Python code. Any solution where you need to modify sudoers every time the code changes is painful, because there is only one sudo configuration on a machine and it's owned by root. We used to use pure sudo, you know. The end result was that the sudoers file were not maintained and everyone ran and tested with a convenient blanket-permission sudoers file. Missing rules were discovered at packaging money time, or after release. Those were the cactus days, and this is the nightmare rootwrap was designed to solve. It does more than just slowing down command execution. Additional filtering was a request from the Linux distros, since they didn't like the lack of precise filtering in our pure-sudo original design. > So I propose we do the following: > - switch back to sudo except for commands where we are not willing to > accept the security implications - case by case basis. Could you expand on how you would 'switch back to sudo' ? The devil is unfortunately in the details. Would you ship a sudoers file within the code and get that somehow picked up by devstack and distros ? What would that sudoer file contain exactly ? Rules for all nodes ? just nova-network ? > - discuss with sudo upstream how to encode the business rules we need > in sudo [if a sudo gate is capable of doing them - not everything will > be like that] > > I appreciate that 'a better solution is needed', but the one we came > up with has nothing fundamentally better than sudo, other than > 'written in python' and 'accepts custom plugins but we aren't using > that yet' : I claim YAGNI. The "custom plugins" are already in use (see KillFilter, ReadFileFilter, EnvFilter...). And again, rootwrap is not reinventing sudo. It just applies additional filtering in a convenient and distro-friendly way. Yes, it was clearly not designed for performance, and so it fails in corner cases (the soon to be deprecated nova-network). I still think we can address those corner cases by grouping calls, rather than throwing the baby out with the bath water. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev