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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:52 UTC