Dmitry, I mean whole feature. Btw, why do you want to grant capabilities via puppet? It should be done by post-install package section, I believe.
Also I doesn't know if supervisord can bound process capabilities like systemd can - we could use this opportunity too. On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <dnikis...@mirantis.com> wrote: > My main concern with using linux capabilities/acls on files is actually > puppet support or, actually, the lack of it. ACLs are possible AFAIK, but > we'd need to write a custom type/provider for capabilities. I suggest to > wait with capabilities support till systemd support. > > On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <dnikis...@mirantis.com> > wrote: > >> Stanislaw, do you mean the whole feature, or just a user? Since feature >> would require actually changing puppet code. >> >> On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin < >> sbogat...@mirantis.com> wrote: >> >>> Dmitry, I believe it should be done via package spec as a part of >>> installation. >>> >>> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <dnikis...@mirantis.com >>> > wrote: >>> >>>> Hello folks, >>>> >>>> I have updated the spec, please review and share your thoughts on it: >>>> https://review.openstack.org/#/c/243340/ >>>> >>>> Thanks. >>>> >>>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov < >>>> dnikis...@mirantis.com> wrote: >>>> >>>>> Matthew, >>>>> >>>>> sorry, didn't mean to butcher your name :( >>>>> >>>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov < >>>>> dnikis...@mirantis.com> wrote: >>>>> >>>>>> Matther, >>>>>> >>>>>> I totally agree that each daemon should have it's own user which >>>>>> should be created during installation of the relevant package. Probably I >>>>>> didn't state this clear enough in the spec. >>>>>> >>>>>> However, there are security requirements in place that root should >>>>>> not be used at all. This means that there should be a some kind of >>>>>> maintenance or system user ('fueladmin'), which would have enough >>>>>> privileges to configure and manage Fuel node (e.g. run "sudo puppet >>>>>> apply" >>>>>> without password, create mirrors etc). This also means that certain fuel- >>>>>> packages would be required to have their files accessible to that user. >>>>>> That's the idea behind having a package which would create 'fueladmin' >>>>>> user >>>>>> and including it into other fuel- packages requirements lists. >>>>>> >>>>>> So this part of the feature comes down to having a non-root user with >>>>>> sudo privileges and passwordless sudo for certain commands (like 'puppet >>>>>> apply <path-to-host-only.pp>') for scripting. >>>>>> >>>>>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn < >>>>>> mmoses...@mirantis.com> wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Nikishov, >>>>>> Deployment Engineer, >>>>>> Mirantis, Inc. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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. >> > > > > -- > 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