Dmitry, 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. I think it makes the most sense to create multiple users, one for each service.
Lastly, it makes a lot of sense to tie a "fuel" CLI user to python-fuelclient package. On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <dnikis...@mirantis.com> wrote: > Stanislaw, > > 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. > > I'm going to research if it is possible to manage capabilities and ACLs > with what we have out of the box (RPM, Puppet). > > On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin < > sbogat...@mirantis.com> wrote: > >> 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. >> >> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <dnikis...@mirantis.com >> > wrote: >> >>> Stanislaw, >>> >>> 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). >>> >>> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov < >>> dnikis...@mirantis.com> wrote: >>> >>>> 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. >>>> >>> >>> >>> >>> -- >>> 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 >>> >>> >> >> __________________________________________________________________________ >> 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 > >
__________________________________________________________________________ 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