Open Stack

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 <dnikishov at 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 <
> sbogatkin at 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 <dnikishov at 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 <
>>> dnikishov at 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 <
>>>> sbogatkin at 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 <
>>>>> bpiotrowski at 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 <aheczko at 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 <
>>>>>>> dnikishov at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151112/46a6f6a8/attachment.html>