Previously, CheckChange (corresponding to Linux's tty/tty_check_change()) was
only used the host TTY implementation, not the devpts implementation.
Furthermore, ThreadGroup.SetForegroundProcessGroup() duplicated some of the
logic in CheckChange, notably sending SIGTTOU to background tasks. This means
that, for host TTYs, we could send SIGTTOU multiple times. In some
circumstances, this leads the ioctl returning ERESTARTSYS in an infinite loop.
PiperOrigin-RevId: 735934036
Exec'd processes cannot be stitched back to the original caller
and are killed after restore. So ignore failures
to restore host FDs (generally stdio) that belong
to them.
Fixes#11439
PiperOrigin-RevId: 732972054
The logic is the same as Linux's __tty_check_change, but we forgot to check the
case that the tty does not have an associated process group.
PiperOrigin-RevId: 693119939
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.
So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.
This is analogous to how sentry-internal tty's already work.
Updates #10925
PiperOrigin-RevId: 681957240
This ensures that host FDs are not using some random FD
upon restore. All host FDs must be part of the restore
FD map that is explicity set, otherwise restore fails.
Updates #1956
PiperOrigin-RevId: 615581166
FD numbers can vary between depending on the options used with
runsc command. For example, there are extra FDs passed to
`runsc boot` if `debug-log` is enabled. So instead of requiring
all FDs to have the exact same numbering during restore, provide
a mechanism to remap the FD. Each host FD has a unique identifier
with a map to their corresponding FD. Then during restore, FD
numbers are remapped to the correct ones.
Updates #1956
PiperOrigin-RevId: 615215783
These inodes can never be part of a filesystem tree. They are nameless and
never have a parent.
This allows us to avoid taking a lock in kernfs.InotifyWithParent for such
anonymous inodes.
PiperOrigin-RevId: 538823227
This commit adds support for program execution via a host file
descriptor. To make use of this feature, the host file descriptor must
be provided to the --exec-fd argument. For example,
exec 3</usr/bin/echo
runsc exec --exec-fd=3 mycontainer hello world
will run the host's echo binary inside gVisor. In this case, "hello" is
supplied to echo as argv[0]. As a result, the output of the above
command is "world".
This feature is useful for bootstrapping unknown guest environments and
allows static executables to perform setup actions inside the container
while they need not be part of the guest file system.
This catches up the interface to the `EmitUnimplementedEvent` method signature
on `kernel.Kernel`.
Also add build-time test to verify that `kernel.Kernel` implements this
interface, in order to catch such breakages at build time in the future.
PiperOrigin-RevId: 519000411
This is consistent with Linux. Some applications recursively add
files to inotify FD. They fail if they run into kernfs files
because inotify_add_watch(2) returns EPERM in that case.
PiperOrigin-RevId: 462642204
fchmod(2) is not part of sentry's seccomp filters. So the sentry
should not be trying to make this syscall. Instead we will error
out gracefully. Violating seccomp filters will kill the entire
sandbox.
There was only one instance in host filesystem (both in VFS1
and VFS2). I am only fixing VFS2, because VFS1 is already
deprecated. I manually checked that all other host syscalls
made by fsimpl/host are allowed by sentry seccomp filters.
PiperOrigin-RevId: 460335687
Since refsvfs2 are used in netstack, we should use atomicbitops to avoid
breaking 32-bit builds.
On 64-bit builds there is no performance difference.
PiperOrigin-RevId: 439687980
Linux behaves differently for regular files and dirs for poll(2)/select(2)
compared to epoll_ctl(2). The latter returns EPERM for file and dirs.
I've also changed host FDs to behave like the underlying FD in regards
to epoll to keep it compatible with docker.
Fixes#7134
PiperOrigin-RevId: 429412692
