Re: [ovs-discuss] Handling conf.db ownership on OVS_USER_ID changes
On Tue, 23 Apr 2019 at 09:30, Jaime Caamaño Ruiz wrote: > > Hello > > So the non root owned log directory (and run directory) is shared > between non root OVS processes and root OVN processes. Doesn't this > raise some security concerns? As a "security concern" you mean something among the lines where one of ovs-* processes running under openvswitch user would go ahead and create a file with its owner that later one of ovn processes would blindly reuse without checking that it actually belongs to root:root? > > Also, since logrotate rotates the logs with the OVS user, it may fail > to some extent to rotate the root owned OVN log files. Consequences > vary but in it's current state some logging might be lost. This could > be improved but I would guess that the approprioate thing to do is to > etiher use a different log directory for OVN or make its processes run > with the OVS user also. Has any of this been considered? Can you give a more concrete example? I believe logrotate is running under root and should be able to rotate everything? > > BR > Jaime. > > > -Original Message- > From: Jaime Caamaño Ruiz > Reply-to: jcaam...@suse.com > To: Ansis Atteka > Cc: ovs-discuss@openvswitch.org, Ben Pfaff > Subject: Re: [ovs-discuss] Handling conf.db ownership on OVS_USER_ID > changes > Date: Wed, 17 Apr 2019 12:52:32 +0200 > > > You also need to chown /var/log/openvswitch.*.log files. > > OVS seems to be already handling this. I dont know the details but I > guess that before dropping capabilities, OVS chowns these by itself. > > > However, > > what about other daemons, like ovn? Do they share run time dir? > > Haven't looked into this in a while and don't have a setup to check > > myself. > > The permisions of the openvswitch run directory are already being > handled by the service unit file. There is read access to files created > there by OVS and AFAIK what it ultimately makes it a no problem for OVN > is that it still runs as root with the provided unit files. If anyone > changes this to a user different than the openvswitch user, then that > is an already existing issue. Am I missing something here? > > Agree with you other considerations. > > BR > Jaime. > > -Original Message- > From: Ansis Atteka > To: jcaam...@suse.de > Cc: ovs-discuss@openvswitch.org, Ben Pfaff > Subject: Re: [ovs-discuss] Handling conf.db ownership on OVS_USER_ID > changes > Date: Tue, 16 Apr 2019 18:21:48 -0700 > > On Tue, 16 Apr 2019 at 17:20, Jaime Caamaño Ruiz > wrote: > > > > My intention was doing it at systemd unit (prestart) for file conf.db > > (and .conf.db.~lock~ that stays around) only. > > You also need to chown /var/log/openvswitch.*.log files. > > > > I was not thinking on absolutely fool proof mechanism, among other > > things because the admin might have customized the location for the > > database. Also, updating and restarting the service are things that > > would usually be monitored. So best effort. > > make sure that best effort solution informs admin in case of error so > that he does not have to go file by file to find the offending one. > > > > > At systemd unit prestart the service is stopped and OVS nor nobody > > should really be messing with the database files owned by OVS. If the > > spec file is changing things back to root unappropriately then that > > should be changed too. > > Yes. > > > > > The runtime /run/openvswitch directory is also controlled by systemd > > and at least on my system is removed if the service is not active, > > either by graceful or ungraceful exit. > > I somewhat agree with this, because back in those days we were using > SystemV where the init.d managed lifecycle of run directory.. However, > what about other daemons, like ovn? Do they share run time dir? > Haven't looked into this in a while and don't have a setup to check > myself. > > > > > I guess we will need to look for specific issues. Any hint to find > > that > > patch? > > 1. test upgrade to your patched OVS and also from your patched OVS to > another future version > 2. if you change existing spec files that are shared with on Fedora or > RHEL/CentOS make sure you don't break anything for them. > 3. prefer consistency w.r.t. default behavior across deb and rpm > packages (if you change user by default consider to do that for all > platforms) > 4. besides database you will also need to set right access bits to log > files. On my Ubuntu it is "-rw-r- 1 root adm " which means: > 4.1. you have to chown it; OR > 4.2. add openvswitch user to adm group and chmod that file > 5. test logrotation. Maybe you can use a one forced logrotation > invocation to change the ownrer. > 6. check that other stuff like ovs-monitor-ipsec is not affected. It > stil need to talk with StrongSwan or libreswan that best to my > knowledge still runs as root. > 7. if you use USER= then: > 7.1. For Linux datapath make sure you retain CAP_NET_ADMIN Linux > Capabilities > 7.2. I don't know if there are special
[ovs-discuss] High CPU load on failvoer using HA_Chassis_Group
Hi folks,
While working on a multinode setup and created this logical topology
[0] where I scheduled a router on two gateway chassis, I found out
that after bringing down ovn-controller on the chassis where the gw
port is master, then the second chassis observes 100% CPU load on
ovn-controller and around 400Kbps from SB ovsdb-server. The events I
receive are related to the HA_Chassis_Group table:
{"HA_Chassis_Group":{"8a1b0b28-69f9-431a-bc4a-2374c59860b6":{"ha_chassis":["set",[["uuid","540d8f3a-8556-43d2-851b-f04bf9429ecd"],["uuid","d6ec9d15-4122-4f14-b8a7-2d1074b8267d"]]]}},"_date":1556110328458,"HA_Chassis":{"49bd7408-6442-473e-9d5b-6913f5a1e681":null,"540d8f3a-8556-43d2-851b-f04bf9429ecd":{"priority":20},"de2f1638-9a0b-4608-98d0-9399eee8d471":null,"d6ec9d15-4122-4f14-b8a7-2d1074b8267d":{"chassis":["uuid","4f1ac159-9fd5-4856-9ae2-8e16a193463e"],"priority":10}}}
OVSDB JSON 476 d8cc6f694a0ad69c4701aebfaa9a5ae2398c172b
{"HA_Chassis_Group":{"8a1b0b28-69f9-431a-bc4a-2374c59860b6":{"ha_chassis":["set",[["uuid","90ba76f6-965d-49a9-89de-c38a989d375b"],["uuid","af977a93-a3d8-455f-b044-0f21c0f37dec"]]]}},"_date":1556110328461,"HA_Chassis":{"90ba76f6-965d-49a9-89de-c38a989d375b":{"chassis":["uuid","4f1ac159-9fd5-4856-9ae2-8e16a193463e"],"priority":10},"540d8f3a-8556-43d2-851b-f04bf9429ecd":null,"af977a93-a3d8-455f-b044-0f21c0f37dec":{"priority":20},"d6ec9d15-4122-4f14-b8a7-2d1074b8267d":null}}
OVSDB JSON 476 b4df3460600c0af2f3132cd7808ad5574eaa5323
{"HA_Chassis_Group":{"8a1b0b28-69f9-431a-bc4a-2374c59860b6":{"ha_chassis":["set",[["uuid","eb80ea97-bb4b-4deb-82ad-35a4d830a20f"],["uuid","f38514f2-bfcf-4ff4-9cc6-d19a76b868ea"]]]}},"_date":1556110328463,"HA_Chassis":{"90ba76f6-965d-49a9-89de-c38a989d375b":null,"f38514f2-bfcf-4ff4-9cc6-d19a76b868ea":{"priority":20},"eb80ea97-bb4b-4deb-82ad-35a4d830a20f":{"chassis":["uuid","4f1ac159-9fd5-4856-9ae2-8e16a193463e"],"priority":10},"af977a93-a3d8-455f-b044-0f21c0f37dec":null}}
OVSDB JSON 476 e3106ae2b527fc5000b8663b5df283f726d2ffec
{"HA_Chassis_Group":{"8a1b0b28-69f9-431a-bc4a-2374c59860b6":{"ha_chassis":["set",[["uuid","05365741-39fe-4a43-83ed-6f8e31322155"],["uuid","771fd1db-8b5c-4d5d-9e74-4ac628ae01ff"]]]}},"_date":1556110328465,"HA_Chassis":{"f38514f2-bfcf-4ff4-9cc6-d19a76b868ea":null,"05365741-39fe-4a43-83ed-6f8e31322155":{"chassis":["uuid","4f1ac159-9fd5-4856-9ae2-8e16a193463e"],"priority":10},"771fd1db-8b5c-4d5d-9e74-4ac628ae01ff":{"priority":20},"eb80ea97-bb4b-4deb-82ad-35a4d830a20f":null}}
OVSDB JSON 476 13ffdecbf19116a2ecd74d3c754d442d11e3dc14
{"HA_Chassis_Group":{"8a1b0b28-69f9-431a-bc4a-2374c59860b6":{"ha_chassis":["set",[["uuid","6b82fb26-b448-4e61-9543-30f21e7f9e9a"],["uuid","e7ac036f-bf94-4a75-847c-c3fd6a87269e"]]]}},"_date":1556110328467,"HA_Chassis":{"05365741-39fe-4a43-83ed-6f8e31322155":null,"e7ac036f-bf94-4a75-847c-c3fd6a87269e":{"chassis":["uuid","4f1ac159-9fd5-4856-9ae2-8e16a193463e"],"priority":10},"771fd1db-8b5c-4d5d-9e74-4ac628ae01ff":null,"6b82fb26-b448-4e61-9543-30f21e7f9e9a":{"priority":20}}}
OVSDB JSON 546 88601aae13e44a53c5a91bbb90ed08e7e480a9f5
{"Chassis":{"c88b7db8-82c1-4deb-803e-ebf7d4e9a077":{"name":"gw1","hostname":"gw1","encaps":["uuid","0d994cfd-bebf-4321-9fdb-81029003bea0"],"external_ids":["map",[["datapath-type",""],["iface-types","erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan"],["ovn-bridge-mappings","external:br-ex"]]]}},"Encap":{"0d994cfd-bebf-4321-9fdb-81029003bea0":{"ip":"192.168.50.102","options":["map",[["csum","true"]]],"chassis_name":"gw1","type":"geneve"}},"_date":1556110328468,"_comment":"ovn-controller:
registering chassis 'gw1'"}
[0]
https://github.com/danalsan/vagrants/blob/master/ovn-playground/create_ovn_resources.sh
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
