Angus Lees wrote:
[...]
None of these are great, but:
Possibility 1: Backdoor rootwrap
However if we assume rootwrap already exists then we _could_ rollout a
new version of oslo.rootwrap that contains a backdoor that allows
privsep-helper to be run as root for any context, without the need to
install a new rootwrap filter.
Disclaimers:
- It wouldn't work for virtualenvs, because the "privsep-helper"
executable won't be in sudo's usual PATH.
- Retro-fitting something like that to rootwrap feels like it's skirting
close to some sort of ethical contract we've made with admins regarding
rootwrap's featureset. Not saying we shouldn't do it, just that we
should think about how an operator is going to feel about that.
Possibility 2: Wider rootwrap filter
In the past, I've been proposing rootwrap filters that match only
specific privsep "privileged contexts" by name. On further reflection,
if we're assuming the existing python modules installed into root's
python path are already trustworthy (and we _are_ assuming that), then
it might also be reasonable to trust *any* privsep entrypoint declared
within that module path. This gives a larger attack surface to think
about (particularly if python libraries including privsep decorators
were installed for some reason other than providing privsep entry
points), but there's no reason why this is _necessarily_ an issue.
This allows us to get to a single rootwrap filter per-project (or
rather, "per-rootwrap") since projects use separate rootwrap config
directories - so we would still have to do a thing once per project.
Possibility 3: Skip rootwrap, use just sudo
sudoers isn't very expressive - but we could install a new rootwrap-like
wrapper into sudoers once system-wide, which includes some sort of logic
to start privsep-helpers. This could be as simple as a small shell
script. The advantage this has over rootwrap is that it would contain
some sort of system-wide config, rather than per-project.
Downsides
- Would still need to be installed once system-wide.
- Would need to be configured per-virtualenv, since otherwise we have no
way to know which virtualenvs should be given root powers.
Possibility 4: Run as root initially
Another option would be to follow the usual Unix daemon model: Start the
process with all required privileges, and avoid sudo/rootwrap entirely.
In this version, we take a once-off hit to tell everyone to start
running their OpenStack agents as root (probably from init/systemd), and
right at the top of main() we fork() the privsep-helper and then drop to
a regular uid. No sudo or rootwrap ever (although the unprivileged code
could continue to use it while we clean up all the legacy code).
A glorious future, but still a big per-project deployment change that
has to be managed somehow.
I'm adding Possibility (0): change Grenade so that rootwrap filters from
N+1 are put in place before you upgrade.
No perfect answer here... I'm hesitating between (0), (1) and (4). (4)
is IMHO the right solution, but it's a larger change for downstream. (1)
is a bit of a hack, where we basically hardcode in rootwrap that it's
being transitioned to privsep. That's fine, but only if we get rid of
rootwrap soon. So only if we have a plan for (4) anyway. Option (0) is a
bit of a hard sell for upgrade procedures -- if we need to take a hit in
that area, let's do (4) directly...
In summary, I think the choice is between (1)+(4) and doing (4)
directly. How doable is (4) in the timeframe we have ? Do we all agree
that (4) is the endgame ?
--
Thierry Carrez (ttx)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
