Dmitry, I just propose the way I think is right, because it's strange enough - install package from *.deb file and then set any privileges to it by third-party utility. Set permissions for app now mostly managed by post-install scripts. Moreover - if it isn't - it should, cause if you set capabilities by puppet there always will be a gap between installation and setting permissions, so you will must bound package installation process with setting permissions by puppet - other way you will have no way to use your app.
Setting setuid bits on apps is not a good idea - it is why linux capabilities were introduced. On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <dnikis...@mirantis.com> wrote: > Stanislaw, > > In my opinion the whole feature shouldn't be in the separate package > simply because it will actually affect the code of many, if not all, > components of Fuel. > > The only services whose capabilities will have to be managed by puppet are > those, which are installed from upstream packages (e.g. atop) -- not built > from fuel-* repos. > > Supervisord doesn't seem to use Linux capabilities, id does setuid > instead: > https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326 > > On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin < > sbogat...@mirantis.com> wrote: > >> 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 >> >> > > > -- > 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
