<div dir="ltr"><div><div>Dmitry,<br><br></div>We really shouldn't put "user" creation into a single package and then depend on it for daemons. If we want nailgun service to run as nailgun user, it should be created in the fuel-nailgun package.<br></div><div>I think it makes the most sense to create multiple users, one for each service.<br><br></div><div>Lastly, it makes a lot of sense to tie a "fuel" CLI user to python-fuelclient package. <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw,<div><br></div><div>I agree that this approch would work well. However, does Puppet allow managing capabilities and/or file ACLs? Or can they be easily set up when installing RPM package? (is there a way to specify capabilities/ACLs in the RPM spec file?) This doesn't seem to be supported out of the box.</div><div><br></div><div>I'm going to research if it is possible to manage capabilities and  ACLs with what we have out of the box (RPM, Puppet).</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dmitry, I propose to give needed linux capabilities (like CAP_NET_BIND_SERVICE) to processes (services) which needs them and then start these processes from non-privileged user. It will give you ability to run each process without 'sudo' at all with well fine-grained permissions.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw,<div><br></div><div>I've been experimenting with 'capsh' on the 6.1 master node and it doesn't seem to preserve any capabilities when setting SECURE_NOROOT bit, even if explicitely told to do so (via either --keep=1 or "SECURE_KEEP_CAPS" bit).</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Bartolomiej, Adam,<div>Stanislaw is correct. And this is going to be ported to master. The goal currently is to reach an agreement on the implementation so that there's going to be a some kinf of compatibility during upgrades.<br></div><div><br></div><div>Stanislaw,</div><div>Do I understand correctly that you propose using something like sucap to launch from root, switch to a different user and then drop capabilities which are not required?</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Bartolomiej, it's customer-related patches, they, I think, have to be done for 6.1 prior to 8+ release.<div><br></div><div>Dmitry, it's nice to hear about it. Did you consider to use linux capabilities on fuel-related processes instead of just using non-extended POSIX privileged/non-privileged permission checks?</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <span dir="ltr"><<a href="mailto:bpiotrowski@mirantis.com" target="_blank">bpiotrowski@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We don't develop features for already released versions… It should be done for master instead.<span><font color="#888888"><div><br></div><div>BP</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko <span dir="ltr"><<a href="mailto:aheczko@mirantis.com" target="_blank">aheczko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dmitry,<div>+1</div><div><br></div><div>Do you plan to port your patchset to future Fuel releases?</div><div><br></div><div>A.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>Hey guys.</div><div><br></div><div>I've been working on making Fuel not to rely on superuser privileges</div><div>at least for day-to-day operations. These include:</div><div>a) running Fuel services (nailgun, astute etc)</div><div>b) user operations (create env, deploy, update, log in)</div><div><br></div><div>The reason for this is that many security policies simply do not</div><div>allow root access (especially remote) to servers/environments.</div><div><br></div><div>This feature/enhancement means that anything that currently is being</div><div>run under root, will be evaluated and, if possible, put under a non-privileged</div><div>user. This also means that remote root access will be disabled.</div><div>Instead, users will have to log in with "fueladmin" user.</div><div><br></div><div>Together with Omar <gomarivera> we've put together a blueprint[0] and a</div><div>spec[1] for this feature. I've been developing this for Fuel 6.1, so there</div><div>are two patches into fuel-main[2] and fuel-library[3] that can give you an</div><div>impression of current approach.</div><div><br></div><div>These patches do following:</div><div>- Add fuel-admin-user package, which creates 'fueladmin'</div><div>- Make all other fuel-* packages depend on fuel-admin-user</div><div>- Put supervisord under 'fueladmin' user.</div><div><br></div><div>Please review the spec/patches and let's have a discussion on the approach to</div><div>this feature.</div><div><br></div><div>Thank you.</div><div><br></div><div>[0] <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser</a></div><div>[1] <a href="https://review.openstack.org/243340" target="_blank">https://review.openstack.org/243340</a></div><div>[2] <a href="https://review.openstack.org/243337" target="_blank">https://review.openstack.org/243337</a></div><div>[3] <a href="https://review.openstack.org/243313" target="_blank">https://review.openstack.org/243313</a></div><span><font color="#888888"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</font></span></div></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>