From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 21:11:54 2014 Return-Path: Delivered-To: current@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 B9AD3827 for ; Mon, 8 Sep 2014 21:11:54 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E66D1D49 for ; Mon, 8 Sep 2014 21:11:53 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id v6so1761430lbi.27 for ; Mon, 08 Sep 2014 14:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ekR8K4xSDoEyykxnr01zWGUSY+vMPGLh8hBoh90oiPg=; b=k5Tlc/u/72AHsBopgXhBhQG2wiuj871Ib6wlje9J+n1zGy5WlIUnXkUi91RIiomsKg HCZPXN9b8oTeGl7BwU4IHxoAMjSWJj8QxgKgC8enaXLrj7Yqs/qYvtszdFsRzi569IIH x2j8kbnU2D458Q0r/bGi/NKzhwH+Wocx1fHWYbmuVQcqVIvxCpTJQ8wWKvwHGcnBUG/7 vWW+LiN+qpUVnxBLJeOouc5vK4zzlR61WeDH4BrXkUuqQ2oY6KmI7QXUd7dGz3LHma7j ylkdg0N326XrjmgfR51AGHFmj+B0h/tBwIlGMyAXcj54jVp+0a586NjQnqRu6eRiav6L RusQ== X-Gm-Message-State: ALoCoQmKiya0jh5nxWB7GRO124zVAqo7vAmnmlDBLcEaUphhSVjZq7Ep132R5QUAE8M1yR/ytX/9 X-Received: by 10.152.23.6 with SMTP id i6mr31616528laf.39.1410208966840; Mon, 08 Sep 2014 13:42:46 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id iq1sm3642953lac.9.2014.09.08.13.42.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Sep 2014 13:42:46 -0700 (PDT) Message-ID: <540E14C4.9080201@freebsd.org> Date: Tue, 09 Sep 2014 00:42:44 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Patrick Kelsey , current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient References: In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: George Neville-Neil X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 21:11:54 -0000 On 09.09.2014 0:28, Patrick Kelsey wrote: > In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the > non-append, write-only path. Consequently, programs that use _ftello() > (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, > write-only files and that use capsicum to restrict capabilities on the > associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and > friends) calls on those files fail with ENOTCAPABLE due to lack of > CAP_FCNTL rights. There appear to be only two affected programs in the > tree - tcpdump and dhclient. This affects both CURRENT and 10-STABLE > (including 10.1-PRERELEASE) > > tcpdump, when configured to write to capture files rotated by size, > fails to rotate and captures indefinitely to the first file in the > series. This can be reproduced by a command such as: tcpdump -i > -C 1 -W 2 -w packets -v > > By inspection, dhclient will fail to trim old data from its client > leases file when rewriting that file with a lesser amount of data than > it currently contains. See the ftruncate() call in > dhclient.c:rewrite_client_leases(). > > The attached patch adds CAP_FCNTL to the limited rights established for > non-append, write-only files used by tcpdump and dhclient. It also > restricts the fcntl rights to CAP_FCNTL_GETFL. > > The current need to have CAP_FCNTL rights in order to get or set the > file position on non-append, write-only files is subtle. Perhaps part > of the answer is to define a CAP_FSEEK right in sys/capability.h that > resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in > rights(4) to note the need for CAP_FCNTL when using ftell() and friends. > > -Patrick Stdio code use fcntl(F_GETFL) already in many places, f.e. fdopen(), freopen(). libc code in general use it in rpc code. According to your note, all that places are currently broken in anyway. I don't think that this read-only fcntl(F_GETFL) which doesn not modify anything deserves any special rights at all (i.e. can be just enabled by default in contrast to F_SETFL), but I am not capsicum expert. -- http://ache.vniz.net/