Includes utimes(2), futimes(2), lutimes(2), futimesat(2), mprotect(2), and
undelete(2). undelete, for now, is tested only in failure mode.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15893
This was correct in the final version on Phabricator, but somehow I screwed
up applying the patch locally.
Reported by: linimon
Pointy-hat-to: asomers
MFC after: 2 weeks
X-MFC-With: 335307
The ad audit class is for administrative commands. This commit adds test
for settimeofday, adjtime, and getfh.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15861
This commit includes extattr_{get_file, get_fd, get_link, list_file,
list_fd, list_link}. It does not include any syscalls that modify, set, or
delete extended attributes, as those are in a different audit class.
Submitted by: aniketpt
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15859
This revision adds auditability tests for stat, lstat, fstat, and fstatat,
all from the fa audit class. More tests from that audit class will follow.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15709
These syscalls are atypical, because each one corresponds to several
different audit events, and they each pass several different audit class
filters.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15657
The only syscalls in this class are close, closefrom, munmap, and revoke.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15650
The only syscalls in this class are rmdir, unlink, unlinkat, rename, and
renameat. Also, set is_exclusive for all audit(4) tests, because they can
start and stop auditd.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15647
truncate and ftruncate are the only syscalls in this class, apart from
certain variations of open and openat, which will be handled in a different
file.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15640
readlink and readlinkat are the only syscalls in this class. open and
openat are as well, but they'll be handled in a different file. Also, tidy
up the copyright headers of recently added files in this area.
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc. (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15636
This change includes the framework for testing the auditability of various
syscalls, and includes changes for the first 12. The tests will start
auditd(8) if needed, though they'll be much faster if it's already running.
The syscalls tested in this commit include mkdir(2), mkdirat(2), mknod(2),
mknodat(2), mkfifo(2), mkfifoat(2), link(2), linkat(2), symlink(2),
symlinkat(2), rename(2), and renameat(2).
Submitted by: aniketp
MFC after: 2 weeks
Sponsored by: Google, Inc (GSoC 2018)
Differential Revision: https://reviews.freebsd.org/D15286
Previously it was possible to connect a socket (which had the
CAP_CONNECT right) by calling "connectat(AT_FDCWD, ...)" even in
capabilties mode. This combination should be treated the same as a call
to connect (i.e. forbidden in capabilities mode). Similarly for bindat.
Disable connectat/bindat with AT_FDCWD in capabilities mode, fix up the
documentation and add tests.
PR: 222632
Submitted by: Jan Kokemüller <jan.kokemueller@gmail.com>
Reviewed by: Domagoj Stolfa
MFC after: 1 week
Relnotes: Yes
Differential Revision: https://reviews.freebsd.org/D15221
A pipe was was left over from a development version of pdeathsig.c and
is not needed.
Process C waits for a signal that'll be generated when process B
exists. Process B waits for process D to send it a byte via pipe_db
before it exits. Process D sends the byte after it has started
ptrace()ing process C. The point of the test is to show that process C
receives the signal because process B exited, even though C has been
reparented to process D. The pipe pipe_cd isn't doing anything useful
(though in an earlier version of the patch it did). Clean that up by
removing the useless pipe.
Submitted by: Thomas Munro
MFC after: 6 days
Differential revision: https://reviews.freebsd.org/D15214
- ptrace__breakpoint_siginfo tests that a SIGTRAP for a software breakpoint
in userland triggers a SIGTRAP with a signal code of TRAP_BRKPT.
- ptrace__step_siginfo tests that a SIGTRAP reported for a step after
stepping via PT_STEP or PT_SETSTEP has a signal code of TRAP_TRACE.
- Use a single list of platforms to define HAVE_BREAKPOINT for platforms
that expose a functional breakpoint() inline to userland. Replace
existing lists of platform tests with HAVE_BREAKPOINT instead.
- Add support for advancing PC past a breakpoint inserted via breakpoint()
to support the existing ptrace__PT_CONTINUE_different_thread test on
non-x86 platforms (x86 advances the PC past the breakpoint instruction,
but other platforms do not). This is implemented by defining a new
SKIP_BREAK macro which accepts a pointer to a 'struct reg' as its sole
argument and modifies the contents to advance the PC. The intention is
to use it in between PT_GETREGS and PT_SETREGS.
Tested on: amd64, i386, mips (after adding a breakpoint() to mips)
MFC after: 1 month
-> PROC_PDEATHSIG_STATUS for consistency with other procctl(2)
operations names.
Requested by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 13 days
Allow processes to request the delivery of a signal upon death of
their parent process. Supposed consumer of the feature is PostgreSQL.
Submitted by: Thomas Munro
Reviewed by: jilles, mjg
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D15106
fget_cap() tries to do a cheaper snapshot of a file descriptor without
holding the file descriptor lock. This snapshot does not do a deep
copy of the ioctls capability array, but instead uses a different
return value to inform the caller to retry the copy with the lock
held. However, filecaps_copy() was returning 1 to indicate that a
retry was required, and fget_cap() was checking for 0 (actually
'!filecaps_copy()'). As a result, fget_cap() did not do a deep copy
of the ioctls array and just reused the original pointer. This cause
multiple file descriptor entries to think they owned the same pointer
and eventually resulted in duplicate frees.
The only code path that I'm aware of that triggers this is to create a
listen socket that has a restricted list of ioctls and then call
accept() which calls fget_cap() with a valid filecaps structure from
getsock_cap().
To fix, change the return value of filecaps_copy() to return true if
it succeeds in copying the caps and false if it fails because the lock
is required. I find this more intuitive than fixing the caller in
this case. While here, change the return type from 'int' to 'bool'.
Finally, make filecaps_copy() more robust in the failure case by not
copying any of the source filecaps structure over. This avoids the
possibility of leaking a pointer into a structure if a similar future
caller doesn't properly handle the return value from filecaps_copy()
at the expense of one more branch.
I also added a test case that panics before this change and now passes.
Reviewed by: kib
Discussed with: mjg (not a fan of the extra branch)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D15047
This behavior is already documented by the man page, and suggested by POSIX.
Reviewed by: jhb
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D15099
Do not build or install pf tests if WITHOUT_PF is set. This fixes the build
failure with WITHOUT_PF=yes.
Reported by: Vladimir Zakharov <zakharov.vv@gmail.com>
There was a memory leak in the DIOCRADDTABLES ioctl() code which could
be triggered by trying to add tables with the same name.
Try to provoke this memory leak. It was fixed in r331225.
MFC after: 1 week
