I forgot to do this in be0e1aaf8f.
This makes us actually install that header into the sysroot, unbreaking
ports like openssl, which previously failed to build with:
"fatal error: Kernel/API/POSIX/winsize.h: No such file or directory"
Before this patch, exec commands were inheriting the environment of the
SSHServer instance while interactive shell spawned with an almost empty
env. Now, both paths start with the same basic environment and also
include modifications requested by the ssh client.
This should improve compatibility in a lot of situations but most
visibly it makes syntax highlighting and autocompletion work in
interactive shells.
The list of default environment variables is heavily inspired by what
OpenSSH is doing. Compared to what it produces on my system, we only
lack XDG_*, SSH_* and DBUS_SESSION_BUS_ADDRESS variables. As noted in
the FIXME the value of PATH also differs.
Now that SSHServer sets us in the user's home directory, there is no
need to block them as they will resolve correctly according to the spec:
"File names starting with a slash are "absolute", and are relative to
the root of the file system. Names starting with any other character
are relative to the user's default directory (home directory)."
Also note that we were only refusing relative paths in the OPEN command,
but STAT was already accepting them (and resolving them incorrectly).
We were already changing the home directory for interactive shells, but
with this change single commands also get executed from the user's home
and SFTP relative paths will also resolve from the correct directory.
(Relative paths are still not allowed in the SFTP layer, but everything
will fall in place once we remove that restriction.)
We now report the actual value instead of simply returning 0/-1. We're
now using the conventional representation for signal-terminated
processes and return an exit-status of 128 + signal number.
This aligns the behavior with both Linux and OpenBSD (and probably all
other implementations of openpty).
This bug was visible in SSHServer, indeed when using an interactive
shell, the start pty size was always the default (80x25) instead of
whatever the client's window is using. It is quite visible with `top`,
which now fills the whole window :^)
With this patch, SSHServer is able to update the pty on the server when
the size of the client's window is updated.
Resizing your terminal emulator's window while being connected to
SSHServer no longer make you disconnect.
While the implementation is functional, it seems to have quite more
latency than with a regular SSH server, so visual artifacts may appear
when aggressively resizing the window.
On Serenity, this uses the equivalent LibC function, otherwise it
defaults to the pretty standard ioctl equivalent.
At the time of writing, it seems that only musl, BSDs and Serenity have
the standardized POSIX function.
Until now, we could only use SSHServer to remotely run single commands
(e.g. `ssh remote command_to_run`). With this patch, we now support
using ssh in the most usual way: starting a remote interactive shell and
then running commands on the host.
This parent will contain the data used for streaming stdin/stdout, the
pid of the child process and a few basic methods required for
subsystems. This refactoring will allow us to easily introduce another
kind of child-managing subsystem, used for interactive shells.
This is a step towards supporting interactive shells with SSHServer.
This request includes the options to create the pty associated with the
shell.
Note that we don't validate or do anything else with the options
themselves. We just store them, and any issues with the values will be
discovered when we actually create the pty during the handling of the
"shell" request.
Use the saved source text instead of trying to read it directly from the
source file, as the source file may be a relative path and the script
could have changed the current working directory which would make the
path invalid.
We already store these glPixelStorei() parameters in
m_unpacking_parameters/m_packing_parameters, but didn't do anything
with them.
Setting these parameters is equivalent to offsetting the input/output
texture data pointer by a constant offset.
Those two always come in pairs so lets do it in one commit. This
doesn't yet support evaluating fields as it's not yet needed and would
require setting up callbacks from the interpreter.
Co-authored-by: RatcheT2497 <[email protected]>
Undefine