Bartolomiej, Adam, 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.
Stanislaw, 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? On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <sbogat...@mirantis.com> wrote: > Bartolomiej, it's customer-related patches, they, I think, have to be done > for 6.1 prior to 8+ release. > > 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? > > On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski < > bpiotrow...@mirantis.com> wrote: > >> We don't develop features for already released versions… It should be >> done for master instead. >> >> BP >> >> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko <ahec...@mirantis.com> >> wrote: >> >>> Dmitry, >>> +1 >>> >>> Do you plan to port your patchset to future Fuel releases? >>> >>> A. >>> >>> On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov < >>> dnikis...@mirantis.com> wrote: >>> >>>> Hey guys. >>>> >>>> I've been working on making Fuel not to rely on superuser privileges >>>> at least for day-to-day operations. These include: >>>> a) running Fuel services (nailgun, astute etc) >>>> b) user operations (create env, deploy, update, log in) >>>> >>>> The reason for this is that many security policies simply do not >>>> allow root access (especially remote) to servers/environments. >>>> >>>> This feature/enhancement means that anything that currently is being >>>> run under root, will be evaluated and, if possible, put under a >>>> non-privileged >>>> user. This also means that remote root access will be disabled. >>>> Instead, users will have to log in with "fueladmin" user. >>>> >>>> Together with Omar <gomarivera> we've put together a blueprint[0] and a >>>> spec[1] for this feature. I've been developing this for Fuel 6.1, so >>>> there >>>> are two patches into fuel-main[2] and fuel-library[3] that can give you >>>> an >>>> impression of current approach. >>>> >>>> These patches do following: >>>> - Add fuel-admin-user package, which creates 'fueladmin' >>>> - Make all other fuel-* packages depend on fuel-admin-user >>>> - Put supervisord under 'fueladmin' user. >>>> >>>> Please review the spec/patches and let's have a discussion on the >>>> approach to >>>> this feature. >>>> >>>> Thank you. >>>> >>>> [0] https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser >>>> [1] https://review.openstack.org/243340 >>>> [2] https://review.openstack.org/243337 >>>> [3] https://review.openstack.org/243313 >>>> >>>> -- >>>> Dmitry Nikishov, >>>> Deployment Engineer, >>>> Mirantis, Inc. >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Adam Heczko >>> Security Engineer @ Mirantis Inc. >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >>> >> >> __________________________________________________________________________ >> 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 >> >> > > __________________________________________________________________________ > 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 > > -- Dmitry Nikishov, Deployment Engineer, Mirantis, Inc.
__________________________________________________________________________ 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
