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
> <ifname> -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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to