mirror of
https://github.com/google/nsjail.git
synced 2026-08-30 18:41:30 -07:00
935cd6e0b8
These path based syscalls are not in kTracedSyscalls, and the generated policy
ends in DEFAULT ALLOW, so they run unobserved and never reach the report.
Measured against the report of a run under --seccomp_unotify, using the glibc
wrappers rather than raw syscall numbers, on a file and on a symlink to it:
truncate() shrank the file from 21 to 3 bytes inside the jail, verified from
outside. The report attributed no truncate to that path.
setfattr set an attribute on a file inside the jail; the attribute was still
there after the run, and the report attributed nothing to that path.
glibc faccessat(AT_EACCESS) produced no entry at all, and no faccessat
appeared either, so glibc had issued faccessat2.
faccessat2 is the same case as the statx entry added in c20246a: modern glibc
reaches for it first and only falls back to the traced faccessat on older
kernels. A plain access(2) is still traced by its own entry; what goes unseen
is the check made through faccessat().
truncate changes a file's contents without opening it, so nothing in the report
marks that path as written.
The l* variants are listed separately, the same way stat and lstat are, and are
exercised through a symlink so that all eleven entries are covered.
The flags argument of faccessat2 is left undecoded, the same as every other
AT_* entry in the table.