Jaime Caamaño Ruiz <[email protected]> writes: >> 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.
This is the magic of logrotate.d configuration. It will automatically move the file. The permissions/ownership. are only changed on /var/log/openvswitch/ 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. > > 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? No, this is correct. > Agree with you other considerations. We do not change the user configuration on upgrade. It's set *ONLY* when the install is a first time install. And that will create an openvswitch user, which will be the setting applied in /etc/sysconfig/openvswitch As Ansis notes, there are a huge number of side effects we need to consider. Even the selinux/root confinements include edge cases (for instance, are there DAC side effects for unlabeled files? Are we accidentally allowing daemon-daemon communication that should be restricted?). Happy to see improvements :) > BR > Jaime. > > -----Original Message----- > From: Ansis Atteka <[email protected]> > To: [email protected] > Cc: [email protected], Ben Pfaff <[email protected]> > 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 <[email protected]> > 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 privileges you need to retain > for DPDK. And in future possibly AF_XDP. > 8. I haven't looked in a while but check if ovn (that has its own > Systemd service file) shares run dir with OVS > >> >> BR >> Jaime. >> >> -----Original Message----- >> From: Ansis Atteka <[email protected]> >> To: [email protected] >> Cc: [email protected], Ben Pfaff <[email protected]> >> Subject: Re: [ovs-discuss] Handling conf.db ownership on OVS_USER_ID >> changes >> Date: Tue, 16 Apr 2019 16:11:44 -0700 >> >> On Tue, 16 Apr 2019 at 15:36, Jaime Caamaño Ruiz <[email protected]> >> wrote: >> > >> > > On any given system, I would expect ovsdb-server to run as the >> > > same >> > > user >> > > every time. Is there a reason to sometimes use a different user? >> > >> > Well, changing from root which was the only supported option in the >> > past and current default to a different user (like the suggested >> > openvswitch), this one time, might be somewhat common. And the >> > scenario >> > that I am looking at is suporting a pianless upgrade through it. >> >> Actually debian packages still by default use "root" user. Not >> "openvswitch". >> >> Long time ago there was an attempt to change the default user across >> all different flavor packages to openvswitch (you can lookup the >> patch >> on mailing list). However, as you noticed upgrades are tricky. Hence >> packages built from our debian/rules and rhel/openvswitch.spec.in >> files still use "root" as default user. The packages built with >> rhel/openvswitch-fedora.spec.in are an exception where the user >> indeed >> is "openvswitch". Unless you passed --without libcapng flag to >> rpmbuild invocation. Then the user would still be "root". >> >> Here are the difficulties with automating the change of file >> ownership: >> 1. from which context to change ownership? As chown must be invoked >> from something that runs under root then there is not much choice - >> either package installation time (%post scriptlet) or daemon startup >> time (assuming you are not using Systemd's USER= feature in spec >> file) >> or something that admin explicitly has to invoke from bash as "root". >> 1.1. if it is package installation time then you can't update user >> gracefully at daemon init time. It will be possible only at >> installation time. >> 1.2. if it is installation time then you can run into weird race >> conditions where some code that was executed under root (as package >> %post scriptlets) or previous instance of OVS that was still running >> as root could change ownership back to root for some files and cause >> unexpected "permission denied" issues (the patch I mentioned was >> affected with these rare race conditions) >> 2. for which files to change ownership? What happens if Unix domain >> socket file remained on fileystem with "root" permissions when OVS >> was >> abruptly killed? What if someone else put a file under ovs >> directories >> with non-root user - should you blindly chown that too? What if %post >> scriptlet that runs under root non-atomically created a file and in >> next line chown() it back - is there a window for race? Should you >> follow directories/symlinks recursively? Changing user for conf.db >> file is not enough... >> >> I am not saying it is impossible to change user gracefully on >> upgrades. I am saying that code may have to be reorganized quite a >> bit >> to eliminate the issues I raised above. >> >> Alternatively, for Centos, RHEL and Fedora one can use SElinux to >> confine processes and leave them running as root (instead of running >> them under limited privilege user). I believe on SUSE (and Debian) >> once could use AppArmor to achieve the same results. At least for >> SElinux it was a little bit easier to make upgrade seamless than with >> Linux user confinement approach. >> >> > >> > So if that makes sense to you, I will go ahead with the patch. >> > >> > BR >> > Jaime. >> > >> > -----Original Message----- >> > From: Ben Pfaff <[email protected]> >> > To: [email protected] >> > Cc: [email protected] >> > Subject: Re: [ovs-discuss] Handling conf.db ownership on >> > OVS_USER_ID >> > changes >> > Date: Tue, 16 Apr 2019 15:25:24 -0700 >> > >> > On Tue, Apr 16, 2019 at 11:32:21PM +0200, Jaime Caamaño Ruiz wrote: >> > > When sysconfig OVS_USER_ID is changed to a different user, it >> > > requires >> > > a manual ownership change of the OVS conf.db database if existing >> > > or >> > > otherwise ovsdb-server will fail to (re)start. I was wondering if >> > > I >> > > am >> > > missing any particular reason why this is change of ownership is >> > > not >> > > automatically being handled through the service unit file as it >> > > is >> > > being done with other items. >> > >> > On any given system, I would expect ovsdb-server to run as the same >> > user >> > every time. Is there a reason to sometimes use a different user? >> > >> > Or, perhaps you are saying that, just before invoking ovsdb-server, >> > the >> > service unit should chown (or whatever) the database file to the >> > user >> > that it is going to use to invoke ovsdb-server. That might be >> > reasonable, but no one has thought to do it yet. Do you want to >> > submit >> > a patch? >> > >> > Thanks, >> > >> > Ben. >> > >> > _______________________________________________ >> > discuss mailing list >> > [email protected] >> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> > > > _______________________________________________ > discuss mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
