Open Stack

Robert Collins wrote:
> On 2 August 2013 20:05, Thierry Carrez <thierry at 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)