[openstack-dev] [tripleo] removing sudoers.d rules from disk-image-builder

Clint Byrum clint at fewbar.com
Fri Jul 26 17:53:30 UTC 2013

Excerpts from Robert Collins's message of 2013-07-25 15:39:13 -0700:
> On 26 July 2013 10:19, Thierry Carrez <thierry at openstack.org> 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

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.

More information about the OpenStack-dev mailing list