Excerpts from Robert Collins's message of 2013-07-25 15:39:13 -0700: > On 26 July 2013 10:19, Thierry Carrez <[email protected]> wrote: > > Chris Jones wrote: > >> I agree with your analysis of the effects of the sudoers file and I > >> think it makes a great argument for recommending people run the main > >> command itself with sudo, rather than a blanket passwordless sudo, but > >> really all we need to say is "this tool needs to be run as root" and let > >> people make their own decision :) > > > > Ideally the tool would detect if it's run with root privileges and > > prompt for password if it's not. That way you have two options: > > - run sudo TOOL (convenient, can run unattended) > > - run TOOL and get prompted (less convenient, slightly more secure) > > > > If the tool is run by a real user I don't think it's worth going through > > the pain of using rootwrap, although it could be used to implement > > smarter privilege escalation rules (like the PathFilter that looks into > > canonical paths and is therefore not vulnerable to linking attacks). > > Many such tools are still vulnerable to race conditions, The only ones > I'm aware of that are not are apparmor and selinux :).
I looked at this and thought "maybe we could maintain AA and SELinux rules!". I think it would reveal that one needs so much access to the system and the internet (or a populated cache...) that it needs to be on a dedicated bastion host anyway, and as others have suggested, running some parts as non-root is mostly to avoid accidentally damaging the build host. To those who would say "but.. the elements..." Like any other software, elements need to be from a trusted source, and/or audited directly. So, to be more clear than my last +1, I think removing the file from the source tree, and documenting that one needs to allow blanket sudo for it to work is a valid step forward. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
