My intention was doing it at systemd unit (prestart) for file conf.db (and .conf.db.~lock~ that stays around) only.
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. 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. 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 guess we will need to look for specific issues. Any hint to find that patch? 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
