From owner-svn-src-all@freebsd.org Mon Oct 7 01:03:15 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C5681396FC; Mon, 7 Oct 2019 01:03:15 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46mj02749vz448Z; Mon, 7 Oct 2019 01:03:14 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BDF626E14; Mon, 7 Oct 2019 01:03:14 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x9713ECd085920; Mon, 7 Oct 2019 01:03:14 GMT (envelope-from kevans@FreeBSD.org) Received: (from kevans@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x9713EwQ085919; Mon, 7 Oct 2019 01:03:14 GMT (envelope-from kevans@FreeBSD.org) Message-Id: <201910070103.x9713EwQ085919@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: kevans set sender to kevans@FreeBSD.org using -f From: Kyle Evans Date: Mon, 7 Oct 2019 01:03:14 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-12@freebsd.org Subject: svn commit: r353157 - in stable: 11/sys/net 12/sys/net X-SVN-Group: stable-12 X-SVN-Commit-Author: kevans X-SVN-Commit-Paths: in stable: 11/sys/net 12/sys/net X-SVN-Commit-Revision: 353157 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 01:03:15 -0000 Author: kevans Date: Mon Oct 7 01:03:14 2019 New Revision: 353157 URL: https://svnweb.freebsd.org/changeset/base/353157 Log: MFC r353103: tuntap(4): loosen up tunclose restrictions Realistically, this cannot work. We don't allow the tun to be opened twice, so it must be done via fd passing, fork, dup, some mechanism like these. Applications demonstrably do not enforce strict ordering when they're handing off tun devices, so the parent closing before the child will easily leave the tun/tap device in a bad state where it can't be destroyed and a confused user because they did nothing wrong. Concede that we can't leave the tun/tap device in this kind of state because of software not playing the TUNSIFPID game, but it is still good to find and fix this kind of thing to keep ifconfig(8) up-to-date and help ensure good discipline in tun handling. Modified: stable/12/sys/net/if_tun.c Directory Properties: stable/12/ (props changed) Changes in other areas also in this revision: Modified: stable/11/sys/net/if_tun.c Directory Properties: stable/11/ (props changed) Modified: stable/12/sys/net/if_tun.c ============================================================================== --- stable/12/sys/net/if_tun.c Sun Oct 6 22:29:02 2019 (r353156) +++ stable/12/sys/net/if_tun.c Mon Oct 7 01:03:14 2019 (r353157) @@ -32,6 +32,7 @@ #include #include #include +#include #include #include #include @@ -493,22 +494,28 @@ tunopen(struct cdev *dev, int flag, int mode, struct t static int tunclose(struct cdev *dev, int foo, int bar, struct thread *td) { + struct proc *p; struct tun_softc *tp; struct ifnet *ifp; + p = td->td_proc; tp = dev->si_drv1; ifp = TUN2IFP(tp); mtx_lock(&tp->tun_mtx); + /* - * Simply close the device if this isn't the controlling process. This - * may happen if, for instance, the tunnel has been handed off to - * another process. The original controller should be able to close it - * without putting us into an inconsistent state. + * Realistically, we can't be obstinate here. This only means that the + * tuntap device was closed out of order, and the last closer wasn't the + * controller. These are still good to know about, though, as software + * should avoid multiple processes with a tuntap device open and + * ill-defined transfer of control (e.g., handoff, TUNSIFPID, close in + * parent). */ - if (td->td_proc->p_pid != tp->tun_pid) { - mtx_unlock(&tp->tun_mtx); - return (0); + if (p->p_pid != tp->tun_pid) { + log(LOG_INFO, + "pid %d (%s), %s: tun/tap protocol violation, non-controlling process closed last.\n", + p->p_pid, p->p_comm, dev->si_name); } /*