| Message ID | cda568ab0ccda1a68e4d4d4b8da6dd0b78be9471.1533549820.git.tredaelli@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [ovs-dev] utilities: Launch ovsdb-tool without using PAM | expand |
Hello Timothy, On 08/06/2018 01:03 PM, Timothy Redaelli wrote: > When ovsdb-server is starting, it performs some DB steps such as > creating and upgrading the OvS DB. When we are running as > 'non-root' user, the 'runuser' tool is used to manage the privileges. > However, when this happens during systemd boot, we observe the following > errors in journald: > > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Failed to add PIDs to > scope's control group: No such process > Jun 21 07:32:57 virt systemd[1]: Failed to start Session c1 of user openvswitch. > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Unit entered failed state. > > According to the analysis performed on openSUSE bugzilla[1], it seems > that ovsdb-server.service creates (via the call to runuser) a user > session and therefore call pam_systemd which in its turn tries to start > a systemd user instance: "user@474.service". However "user@474.service" > is supposed to be started after systemd-user-sessions.service which is > supposed to be started after network.target. Additionally, > ovsdb-server.service uses Before=network.target hence the deadlock. > > This commit uses "setpriv" instead of "runuser" to launch "ovsdb-tool" that > doesn't use PAM and so it permits to launch "ovsdb-tool" as a user without > having the deadlock. Since some old versions for "setpriv" (such as the > one used by RHEL7) doesn't support the username / groupname, but only the > user ids / group ids, "id" is used to get the user ID and the group IDs. > To replicate the same behaviour of "runuser", the effective group ID of > the user is used as GID (usually "openvswitch") and the remaining group > IDs are used as supplementary groups (usually "hugetlbfs", if OVS is > built with DPDK support). > > [1]: https://bugzilla.suse.com/show_bug.cgi?id=1098630 > Reported-by: Markos Chandras <mchandras@suse.de> > Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349716.html > Co-authored-by: Aaron Conole <aconole@redhat.com> > Signed-off-by: Timothy Redaelli <tredaelli@redhat.com> > --- Thank you for the fix Reviewed-by: Markos Chandras <mchandras@suse.de>
Bleep bloop. Greetings Timothy Redaelli, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. checkpatch: ERROR: Too many signoffs; are you missing Co-authored-by lines? ERROR: Co-authored-by/Signed-off-by corruption Lines checked: 64, Warnings: 0, Errors: 2 Please check this out. If you feel there has been an error, please email aconole@bytheb.org Thanks, 0-day Robot
Timothy Redaelli <tredaelli@redhat.com> writes: > When ovsdb-server is starting, it performs some DB steps such as > creating and upgrading the OvS DB. When we are running as > 'non-root' user, the 'runuser' tool is used to manage the privileges. > However, when this happens during systemd boot, we observe the following > errors in journald: > > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Failed to add PIDs to > scope's control group: No such process > Jun 21 07:32:57 virt systemd[1]: Failed to start Session c1 of user openvswitch. > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Unit entered failed state. > > According to the analysis performed on openSUSE bugzilla[1], it seems > that ovsdb-server.service creates (via the call to runuser) a user > session and therefore call pam_systemd which in its turn tries to start > a systemd user instance: "user@474.service". However "user@474.service" > is supposed to be started after systemd-user-sessions.service which is > supposed to be started after network.target. Additionally, > ovsdb-server.service uses Before=network.target hence the deadlock. > > This commit uses "setpriv" instead of "runuser" to launch "ovsdb-tool" that > doesn't use PAM and so it permits to launch "ovsdb-tool" as a user without > having the deadlock. Since some old versions for "setpriv" (such as the > one used by RHEL7) doesn't support the username / groupname, but only the > user ids / group ids, "id" is used to get the user ID and the group IDs. > To replicate the same behaviour of "runuser", the effective group ID of > the user is used as GID (usually "openvswitch") and the remaining group > IDs are used as supplementary groups (usually "hugetlbfs", if OVS is > built with DPDK support). > > [1]: https://bugzilla.suse.com/show_bug.cgi?id=1098630 > Reported-by: Markos Chandras <mchandras@suse.de> > Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349716.html > Co-authored-by: Aaron Conole <aconole@redhat.com> > Signed-off-by: Timothy Redaelli <tredaelli@redhat.com> > --- Thanks all. Signed-off-by: Aaron Conole <aconole@redhat.com>
On Mon, Aug 06, 2018 at 08:33:46AM -0400, Aaron Conole wrote: > Timothy Redaelli <tredaelli@redhat.com> writes: > > > When ovsdb-server is starting, it performs some DB steps such as > > creating and upgrading the OvS DB. When we are running as > > 'non-root' user, the 'runuser' tool is used to manage the privileges. > > However, when this happens during systemd boot, we observe the following > > errors in journald: > > > > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Failed to add PIDs to > > scope's control group: No such process > > Jun 21 07:32:57 virt systemd[1]: Failed to start Session c1 of user openvswitch. > > Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Unit entered failed state. > > > > According to the analysis performed on openSUSE bugzilla[1], it seems > > that ovsdb-server.service creates (via the call to runuser) a user > > session and therefore call pam_systemd which in its turn tries to start > > a systemd user instance: "user@474.service". However "user@474.service" > > is supposed to be started after systemd-user-sessions.service which is > > supposed to be started after network.target. Additionally, > > ovsdb-server.service uses Before=network.target hence the deadlock. > > > > This commit uses "setpriv" instead of "runuser" to launch "ovsdb-tool" that > > doesn't use PAM and so it permits to launch "ovsdb-tool" as a user without > > having the deadlock. Since some old versions for "setpriv" (such as the > > one used by RHEL7) doesn't support the username / groupname, but only the > > user ids / group ids, "id" is used to get the user ID and the group IDs. > > To replicate the same behaviour of "runuser", the effective group ID of > > the user is used as GID (usually "openvswitch") and the remaining group > > IDs are used as supplementary groups (usually "hugetlbfs", if OVS is > > built with DPDK support). > > > > [1]: https://bugzilla.suse.com/show_bug.cgi?id=1098630 > > Reported-by: Markos Chandras <mchandras@suse.de> > > Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349716.html > > Co-authored-by: Aaron Conole <aconole@redhat.com> > > Signed-off-by: Timothy Redaelli <tredaelli@redhat.com> > > --- > > Thanks all. > > Signed-off-by: Aaron Conole <aconole@redhat.com> Thanks, applied to master, backported as far 2.7.
diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in index 10c709792..090a14434 100644 --- a/utilities/ovs-lib.in +++ b/utilities/ovs-lib.in @@ -389,7 +389,10 @@ move_ip_routes () { ovsdb_tool () { if [ "$OVS_USER" != "" ]; then - runuser --user "${OVS_USER%:*}" -- ovsdb-tool -vconsole:off "$@" + local uid=$(id -u "${OVS_USER%:*}") + local gid=$(id -g "${OVS_USER%:*}") + local groups=$(id -G "${OVS_USER%:*}" | tr ' ' ',') + setpriv --reuid "$uid" --regid "$gid" --groups "$groups" ovsdb-tool -vconsole:off "$@" else ovsdb-tool -vconsole:off "$@" fi
When ovsdb-server is starting, it performs some DB steps such as creating and upgrading the OvS DB. When we are running as 'non-root' user, the 'runuser' tool is used to manage the privileges. However, when this happens during systemd boot, we observe the following errors in journald: Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Failed to add PIDs to scope's control group: No such process Jun 21 07:32:57 virt systemd[1]: Failed to start Session c1 of user openvswitch. Jun 21 07:32:57 virt systemd[1]: session-c1.scope: Unit entered failed state. According to the analysis performed on openSUSE bugzilla[1], it seems that ovsdb-server.service creates (via the call to runuser) a user session and therefore call pam_systemd which in its turn tries to start a systemd user instance: "user@474.service". However "user@474.service" is supposed to be started after systemd-user-sessions.service which is supposed to be started after network.target. Additionally, ovsdb-server.service uses Before=network.target hence the deadlock. This commit uses "setpriv" instead of "runuser" to launch "ovsdb-tool" that doesn't use PAM and so it permits to launch "ovsdb-tool" as a user without having the deadlock. Since some old versions for "setpriv" (such as the one used by RHEL7) doesn't support the username / groupname, but only the user ids / group ids, "id" is used to get the user ID and the group IDs. To replicate the same behaviour of "runuser", the effective group ID of the user is used as GID (usually "openvswitch") and the remaining group IDs are used as supplementary groups (usually "hugetlbfs", if OVS is built with DPDK support). [1]: https://bugzilla.suse.com/show_bug.cgi?id=1098630 Reported-by: Markos Chandras <mchandras@suse.de> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349716.html Co-authored-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Timothy Redaelli <tredaelli@redhat.com> --- utilities/ovs-lib.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)