On Tue, 16 Apr 2019 at 16:11, Ansis Atteka <[email protected]> wrote: > > 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) typo: I meant Systemd *service (not spec) file. Albeit I guess with *.service files when using USER= you can still specify Exec= and ExecStartPre= where one runs as confined user and the other runs as root that could chown() files.
One step back .. I am wondering if user downgrade should rather be done through systemd and not with --user flags. Haven't looked into this too closely, but for some of my other non-OVS projects the Systemd user downgrade seems to be working just fine. > 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 typo: instead of "installation time" I meant "daemon startup time" > 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
