Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

Stanislaw,

the reason why I'm considering splitting the blueprint is that along with
implementing the feature, CI jobs and OSTF must be fixed as well.

On Mon, Dec 7, 2015 at 4:03 AM, Stanislaw Bogatkin 
wrote:

> Hi Dmitry,
>
> thank you for an update.
> I personally think that 2 and 3 must be done in one blueprint as it
> related to master node only and 2 shouldn't be a rocket science. What you
> mean by "Non-root accounts on slave nodes"? If we speak about disabling
> root for ssh, creating new user and adding needed commands for him in
> sudoers - I believe that it can be done in that blueprint too. If it is
> something much bigger - it worth to be in separate blueprint.
>
> On Fri, Dec 4, 2015 at 8:24 PM, Dmitry Nikishov 
> wrote:
>
>> Folks, there is another spec update, please take a look:
>> https://review.openstack.org/#/c/243340
>>
>> I'm also considering splitting the blueprint/spec into smaller pieces:
>>
>> 1. Non-root accounts on slave nodes.
>> 2. Non-root user account (fueladmin) on master node.
>> 3. Running fuel services as non-superuser.
>> 4. Running mcollective as non-root (tentative, still need a POC).
>>
>> Let me know what you think.
>>
>> On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov > > wrote:
>>
>>> Folks, I have updated a spec, please review:
>>> https://review.openstack.org/#/c/243340
>>>
>>> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov >> > wrote:
>>>
 Stanislaw,

 proposing patches could be a viable option long-term, however, by the
 time these patches will make it upstream, Fuel will use CentOS 7 w/ 
 systemd.

 On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> Dmitry, as we work on opensource - it would be really nice to propose
> patches to upstream for non-Fuel services. But if it is not an option -
> using puppet make sense to me.
>
> On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <
> dnikis...@mirantis.com> wrote:
>
>> Stanislaw,
>>
>> I want to clarify: there are 2 types of services, run on the Fuel
>> node:
>> - Those, which are a part of Fuel (astute, nailgun etc)
>> - Those, which are not (e.g. atop)
>>
>> Capabilities for the former can easily be managed via post-install
>> scripts, embedded in respective package spec file (since specs are a part
>> of fuel-* repo). This is a very good idea.
>> Capabilities for the latter will have to be taken care of via either
>> a. some external utility (puppet)
>> b. rebuilding respective package with updated spec
>>
>> I'd say that (a) is still more convinient.
>>
>> Another option would be to have a fine-grained control only on Fuel
>> services and leave all the other at their defaults.
>>
>> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> 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 <

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Hi Dmitry,

thank you for an update.
I personally think that 2 and 3 must be done in one blueprint as it related
to master node only and 2 shouldn't be a rocket science. What you mean
by "Non-root
accounts on slave nodes"? If we speak about disabling root for ssh,
creating new user and adding needed commands for him in sudoers - I believe
that it can be done in that blueprint too. If it is something much bigger -
it worth to be in separate blueprint.

On Fri, Dec 4, 2015 at 8:24 PM, Dmitry Nikishov 
wrote:

> Folks, there is another spec update, please take a look:
> https://review.openstack.org/#/c/243340
>
> I'm also considering splitting the blueprint/spec into smaller pieces:
>
> 1. Non-root accounts on slave nodes.
> 2. Non-root user account (fueladmin) on master node.
> 3. Running fuel services as non-superuser.
> 4. Running mcollective as non-root (tentative, still need a POC).
>
> Let me know what you think.
>
> On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov 
> wrote:
>
>> Folks, I have updated a spec, please review:
>> https://review.openstack.org/#/c/243340
>>
>> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov 
>> wrote:
>>
>>> Stanislaw,
>>>
>>> proposing patches could be a viable option long-term, however, by the
>>> time these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.
>>>
>>> On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
 Dmitry, as we work on opensource - it would be really nice to propose
 patches to upstream for non-Fuel services. But if it is not an option -
 using puppet make sense to me.

 On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <
 dnikis...@mirantis.com> wrote:

> Stanislaw,
>
> I want to clarify: there are 2 types of services, run on the Fuel node:
> - Those, which are a part of Fuel (astute, nailgun etc)
> - Those, which are not (e.g. atop)
>
> Capabilities for the former can easily be managed via post-install
> scripts, embedded in respective package spec file (since specs are a part
> of fuel-* repo). This is a very good idea.
> Capabilities for the latter will have to be taken care of via either
> a. some external utility (puppet)
> b. rebuilding respective package with updated spec
>
> I'd say that (a) is still more convinient.
>
> Another option would be to have a fine-grained control only on Fuel
> services and leave all the other at their defaults.
>
> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

Folks, there is another spec update, please take a look:
https://review.openstack.org/#/c/243340

I'm also considering splitting the blueprint/spec into smaller pieces:

1. Non-root accounts on slave nodes.
2. Non-root user account (fueladmin) on master node.
3. Running fuel services as non-superuser.
4. Running mcollective as non-root (tentative, still need a POC).

Let me know what you think.

On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov 
wrote:

> Folks, I have updated a spec, please review:
> https://review.openstack.org/#/c/243340
>
> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov 
> wrote:
>
>> Stanislaw,
>>
>> proposing patches could be a viable option long-term, however, by the
>> time these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.
>>
>> On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Dmitry, as we work on opensource - it would be really nice to propose
>>> patches to upstream for non-Fuel services. But if it is not an option -
>>> using puppet make sense to me.
>>>
>>> On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <
>>> dnikis...@mirantis.com> wrote:
>>>
 Stanislaw,

 I want to clarify: there are 2 types of services, run on the Fuel node:
 - Those, which are a part of Fuel (astute, nailgun etc)
 - Those, which are not (e.g. atop)

 Capabilities for the former can easily be managed via post-install
 scripts, embedded in respective package spec file (since specs are a part
 of fuel-* repo). This is a very good idea.
 Capabilities for the latter will have to be taken care of via either
 a. some external utility (puppet)
 b. rebuilding respective package with updated spec

 I'd say that (a) is still more convinient.

 Another option would be to have a fine-grained control only on Fuel
 services and leave all the other at their defaults.

 On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

Folks, I have updated a spec, please review:
https://review.openstack.org/#/c/243340

On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov 
wrote:

> Stanislaw,
>
> proposing patches could be a viable option long-term, however, by the time
> these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.
>
> On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, as we work on opensource - it would be really nice to propose
>> patches to upstream for non-Fuel services. But if it is not an option -
>> using puppet make sense to me.
>>
>> On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov > > wrote:
>>
>>> Stanislaw,
>>>
>>> I want to clarify: there are 2 types of services, run on the Fuel node:
>>> - Those, which are a part of Fuel (astute, nailgun etc)
>>> - Those, which are not (e.g. atop)
>>>
>>> Capabilities for the former can easily be managed via post-install
>>> scripts, embedded in respective package spec file (since specs are a part
>>> of fuel-* repo). This is a very good idea.
>>> Capabilities for the latter will have to be taken care of via either
>>> a. some external utility (puppet)
>>> b. rebuilding respective package with updated spec
>>>
>>> I'd say that (a) is still more convinient.
>>>
>>> Another option would be to have a fine-grained control only on Fuel
>>> services and leave all the other at their defaults.
>>>
>>> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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 
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 
> 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 
>> 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 ') 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

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 
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 
>> 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 >> > 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 ') 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? 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

Stanislaw,

I want to clarify: there are 2 types of services, run on the Fuel node:
- Those, which are a part of Fuel (astute, nailgun etc)
- Those, which are not (e.g. atop)

Capabilities for the former can easily be managed via post-install scripts,
embedded in respective package spec file (since specs are a part of fuel-*
repo). This is a very good idea.
Capabilities for the latter will have to be taken care of via either
a. some external utility (puppet)
b. rebuilding respective package with updated spec

I'd say that (a) is still more convinient.

Another option would be to have a fine-grained control only on Fuel
services and leave all the other at their defaults.

On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin 
wrote:

> 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 
> 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 >> > 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 ') for scripting.

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Dmitry, as we work on opensource - it would be really nice to propose
patches to upstream for non-Fuel services. But if it is not an option -
using puppet make sense to me.

On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov 
wrote:

> Stanislaw,
>
> I want to clarify: there are 2 types of services, run on the Fuel node:
> - Those, which are a part of Fuel (astute, nailgun etc)
> - Those, which are not (e.g. atop)
>
> Capabilities for the former can easily be managed via post-install
> scripts, embedded in respective package spec file (since specs are a part
> of fuel-* repo). This is a very good idea.
> Capabilities for the latter will have to be taken care of via either
> a. some external utility (puppet)
> b. rebuilding respective package with updated spec
>
> I'd say that (a) is still more convinient.
>
> Another option would be to have a fine-grained control only on Fuel
> services and leave all the other at their defaults.
>
> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> 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 
>> 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

Stanislaw,

proposing patches could be a viable option long-term, however, by the time
these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.

On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin 
wrote:

> Dmitry, as we work on opensource - it would be really nice to propose
> patches to upstream for non-Fuel services. But if it is not an option -
> using puppet make sense to me.
>
> On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov 
> wrote:
>
>> Stanislaw,
>>
>> I want to clarify: there are 2 types of services, run on the Fuel node:
>> - Those, which are a part of Fuel (astute, nailgun etc)
>> - Those, which are not (e.g. atop)
>>
>> Capabilities for the former can easily be managed via post-install
>> scripts, embedded in respective package spec file (since specs are a part
>> of fuel-* repo). This is a very good idea.
>> Capabilities for the latter will have to be taken care of via either
>> a. some external utility (puppet)
>> b. rebuilding respective package with updated spec
>>
>> I'd say that (a) is still more convinient.
>>
>> Another option would be to have a fine-grained control only on Fuel
>> services and leave all the other at their defaults.
>>
>> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> 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 >> > 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

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 
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 
> 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 >> > 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 ') 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.

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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 
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 
>> 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 ') 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 <
>> 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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 
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 
> 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 > > 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 ') 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 <
>> 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

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 
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 
> wrote:
>
>> Matthew,
>>
>> sorry, didn't mean to butcher your name :(
>>
>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov > > 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 ') 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

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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 
wrote:

> Matthew,
>
> sorry, didn't mean to butcher your name :(
>
> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov 
> 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 ') for scripting.
>>
>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn > > 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 >> > 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  > 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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 
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 
> 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 > > 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 
> 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  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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Matthew Mosesohn]

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 
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 > > 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 
>> 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  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, 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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
') for scripting.

On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn 
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 
> 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 
>>> 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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

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 
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 
> 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 
 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  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 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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 
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 
>> 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  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

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Dmitry Nikishov]

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 
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 
>>> 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  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: 

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

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  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 > > 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  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

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Adam Heczko]

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 
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  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

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Bartlomiej Piotrowski]

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  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 
> 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  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