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

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.


Attachment: ftell_cap_rights.patch
Description: Binary data

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to