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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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,

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

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.

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

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

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

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

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

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,

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

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

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

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

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

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?

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

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

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

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,