From owner-freebsd-bugs@FreeBSD.ORG Wed Apr 30 19:00:00 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFDF8A1B for ; Wed, 30 Apr 2014 19:00:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC7CD175C for ; Wed, 30 Apr 2014 19:00:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3UJ00vJ013650 for ; Wed, 30 Apr 2014 19:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3UJ00FB013641; Wed, 30 Apr 2014 19:00:00 GMT (envelope-from gnats) Resent-Date: Wed, 30 Apr 2014 19:00:00 GMT Resent-Message-Id: <201404301900.s3UJ00FB013641@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dirk Engling Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9DFA89F for ; Wed, 30 Apr 2014 18:55:37 +0000 (UTC) Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABE461711 for ; Wed, 30 Apr 2014 18:55:37 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s3UItbaH033556 for ; Wed, 30 Apr 2014 18:55:37 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s3UItbpi033551; Wed, 30 Apr 2014 18:55:37 GMT (envelope-from nobody) Message-Id: <201404301855.s3UItbpi033551@cgiserv.freebsd.org> Date: Wed, 30 Apr 2014 18:55:37 GMT From: Dirk Engling To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: bin/189139: BUG in jail(8) variable substitution, and PATCH X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:00:01 -0000 >Number: 189139 >Category: bin >Synopsis: BUG in jail(8) variable substitution, and PATCH >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Apr 30 19:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Dirk Engling >Release: 9.2 >Organization: >Environment: >Description: The variable substitution of FreeBSD's jail tool yields unexpected results when a parameter has more than one variable to substitute and one of the later variables needs substitution as well. >How-To-Repeat: Consider the simple test case: $A = "A_${B}_C_${D}"; $B = "BBBBB"; $D = "DDDDD_${E}_FFFFF"; $E = "EEEEE"; bar { exec.poststart = "touch /tmp/$A"; } EXPECTED OUTCOME for running "jail -c bar" would be a file with the name /tmp/A_BBBBB_C_DDDDD_EEEEE_FFFFF to be touched (and, of course, the jail bar being created). OBSERVED OUTCOME is a file with the name /tmp/A_BBBDDDDD_EEEEE_FFFFFBB_C_ being created. The reason is the way jail(8) resolves recursive substitutions. In head/usr.sbin/jail/config.c:193 a varoff variable is introduced that handles a shifting offset for multiple variable substitutions per parameter. This varoff is updated after each substitution in line 239 to reflect a new offset into the parameter's string. This ensures that all other variables are substituted at [their insertion point plus varoff] which is the accumulated length of all previously substituted variables. Now in our example, if $A is to be expanded, first ${B} is inserted at offset 2 and varoff becomes 10. When substituting ${D}, the recursion check at line 216 detects that variable $D also needs expansion. It reorders the parameter list, so that the algorithm works on variable $D now. Then it jumps to find_vars at line 191 and properly expands DDDDD_${E}_FFFFF to DDDDD_EEEEE_FFFFF. When the algorithm now returns to expanding $A by entering the loop body again, it finds a re-set varoff variable leading to (the now expanded) variable $D being inserted at the offset 5, where the parser initially would find it (the internal format for $A is approx: { "A__C_", {2, "B"}, {5, "D"}}) and not at the corrected offset 10. >Fix: Get rid of the varoff and replace line 239 with: [struct cfvar *]vv = v; while ((vv = STAILQ_NEXT(vv, tq))) v->pos += vs->len; to make the offset permanent. Find a patch here https://erdgeist.org/arts/software/jail/usr.sbin.jail-substitution.patch >Release-Note: >Audit-Trail: >Unformatted: