NetBSD Problem Report #51963

From paul@whooppee.com  Fri Feb 10 06:13:56 2017
Return-Path: <paul@whooppee.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id B948C7A16F
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 10 Feb 2017 06:13:56 +0000 (UTC)
Message-Id: <20170210061353.C764E16E62@speedy.whooppee.com>
Date: Fri, 10 Feb 2017 14:13:53 +0800 (PHT)
From: paul@whooppee.com
Reply-To: paul@whooppee.com
To: gnats-bugs@NetBSD.org
Subject: sockets in chroot sandbox via null-mounts don't work
X-Send-Pr-Version: 3.95

>Number:         51963
>Category:       kern
>Synopsis:       sockets in chroot sandbox via null-mounts don't work
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 10 06:15:00 +0000 2017
>Closed-Date:    
>Last-Modified:  Sat Feb 28 20:45:01 +0000 2026
>Originator:     Paul Goyette
>Release:        NetBSD 7.99.53
>Organization:
+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+
>Environment:


System: NetBSD speedy.whooppee.com 7.99.53 NetBSD 7.99.53 (SPEEDY 2016-12-31 23:00:24) #1: Sun Jan 1 01:39:34 UTC 2017 paul@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
Sockets within a sandbox created by null-mounts don't work.  See below.

>How-To-Repeat:
1. Start an X server outside of the sandbox
2. Create and mount a sandbox using null-mounts.  The pkgtools/sandbox
   utility can easily do this.  Be sure to add /tmp and /home to the
   list of file-systems which should be null-mounted within the sandbox
3. From outside the sandbox, run xev and observe that it works
4. From inside the sandbox, run xev and note that it fails when trying
   to connect to the unix socket for the X server, with ECONNREFUSED
   (errno = 61)
5. Now, install the net/socat package
6. Use socat to create a socket within the sandbox and relay data to the
   real socket

	socat unix-listen:/path/to/chroot/tmp/.X11-unix/X123,mode=0777,reuseaddr,fork unix-connect:/tmp/.X11-unix/X0 &
7. Use xauth to copy authentication records for the unix:0 server to the
   unix:123 server (handled by socat's listener socket)
8. Make sure your XAUTHORITY file is accessible within the sandbox
9. Re-run xev with '-display unix:123' option and note that it connects!

>Fix:
Not known, but suspicion is that x v->v_socket is never reflected in ther
 layer vnode.  So when unp_connect uses that, it gets nothing.

	...
	/* Acquire v_interlock to protect against unp_detach(). */
	mutex_enter(vp->v_interlock);
	so2 = vp->v_socket;
	if (so2 == NULL) {
		mutex_exit(vp->v_interlock);
		error = ECONNREFUSED;
		goto bad;
	}
	...


>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sun, 03 Jun 2018 07:56:59 +0000
State-Changed-Why:
my 52598 was pretty similar, does the fix for it work for this case too?


State-Changed-From-To: feedback->open
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Thu, 07 Jun 2018 06:28:47 +0000
State-Changed-Why:
Feedback provided - the problem still exists


From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@NetBSD.org
Cc: maya@netbsd.org
Subject: Re: kern/51963: sockets in chroot sandbox via null-mounts don't work
Date: Thu, 7 Jun 2018 14:27:43 +0800 (+08)

 > State-Changed-From-To: open->feedback
 > State-Changed-By: maya@NetBSD.org
 > State-Changed-When: Sun, 03 Jun 2018 07:56:59 +0000
 > State-Changed-Why: my 52598 was pretty similar, does the fix for it
 >                    work for this case too?

 The problem still exists as of a 8.99.18 kernel built from sources 
 updated on 2018-05-27 at 05:42:36 UTC

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/51963 CVS commit: src
Date: Sat, 28 Feb 2026 20:43:29 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sat Feb 28 20:43:28 UTC 2026

 Modified Files:
 	src/distrib/sets/lists/tests: mi
 	src/tests/fs/nullfs: Makefile
 Added Files:
 	src/tests/fs/nullfs: t_ipc.sh

 Log Message:
 Add test case for sockets and fifos through null mounts.

 I would also add a test case of sending and receiving a datagram, but
 nc(1) doesn't seem to have a way to send or receive _one_ datagram;
 as far as I can tell, it just loops forever on datagram sockets, with
 no stopping point because there's no concept of FIN/shutdown().

 PR kern/51963: sockets in chroot sandbox via null-mounts don't work


 To generate a diff of this commit:
 cvs rdiff -u -r1.1413 -r1.1414 src/distrib/sets/lists/tests/mi
 cvs rdiff -u -r1.5 -r1.6 src/tests/fs/nullfs/Makefile
 cvs rdiff -u -r0 -r1.1 src/tests/fs/nullfs/t_ipc.sh

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search