<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, 24 Jun 2016 at 19:13 Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In summary, I think the choice is between (1)+(4) and doing (4)<br>
directly. How doable is (4) in the timeframe we have ? Do we all agree<br>
that (4) is the endgame ?<br></blockquote><div><br></div><div>I don't make predictions about development timelines within OpenStack. </div><div><br></div><div>Yes, I think (4) should be our endgame, and is certainly the most future-proof approach.  I haven't thought through in detail nor spoken with the ops community at all about how disruptive such a transition might be.</div><div><br></div><div>Thinking just now, I suspect any such transition needs a minimum of one (probably 2) release cycles.  Theoretically:</div><div><br></div><div>- introduce top-of-main code that drops to unpriv uid if root (could theoretically be done in current N cycle)</div><div>- change required deployment method during upgrade to release N+1</div><div>- In N+1 cycle require starting as root (or similar)</div><div>- In N+1 change top-of-main code to fork-privsep-then-drop instead of drop-then-later-use-sudo</div><div>- So by the time N+2 is deployed we're done.</div><div><br></div><div>If we want to give more notice and manage a longer deprecation cycle before requiring a start-as-root deployment (and I think we want both these things), then expand as appropriate.</div><div><br></div><div>I suspect the change to deployment method will be easier to communicate and less unpleasant if we do "every" openstack service in the one tear-the-bandaid-off cycle rather than drag this out over years.  This of course requires substantial cross-project consensus, coordination, and timing.   Once the laughing subsides and we assume that isn't going to happen, then we will need something machine-readable and in-tree that correctly communicates the desired per-service approach at that point in time - perhaps we could publish (eg) systemd unit files for our services and adjust those to User=root/not-root as services switch to the new method over time.  This requires communicating when in the upgrade cycle systemd unit files (or the implied equivalents) should be updated, so goto 10 ;)</div><div><br></div><div> - Gus</div></div></div>