`OwnPtrWithCustomDeleter` was a decorator which provided the ability
to add a custom deleter to `OwnPtr` by wrapping and taking the deleter
as a run-time argument to the constructor. This solution means that no
additional space is needed for the `OwnPtr` because it doesn't need to
store a pointer to the deleter, but comes at the cost of having an
extra type that stores a pointer for every instance.
This logic is moved directly into `OwnPtr` by adding a template
argument that is defaulted to the default deleter for the type. This
means that the type itself stores the pointer to the deleter instead
of every instance and adds some type safety by encoding the deleter in
the type itself instead of taking a run-time argument.
Rather than maintaining a list of #ifdef guards to check systems that do
not provide the reentrant version of getgrent, we can use C++ concepts
to let the compiler perform this check for us.
While we're at it, we can also provide this wrapper as fallible to let
the caller TRY calling it.
Rather than maintaining a list of #ifdef guards to check systems that do
not provide the reentrant version of getpwent, we can use C++ concepts
to let the compiler perform this check for us.
While we're at it, we can also provide this wrapper as fallible to let
the caller TRY calling it.
Note that this still keeps the old behaviour of putting things in std by
default on serenity so the tools can be happy, but if USING_AK_GLOBALLY
is unset, AK behaves like a good citizen and doesn't try to put things
in the ::std namespace.
std::nothrow_t and its friends get to stay because I'm being told that
compilers assume things about them and I can't yeet them into a
different namespace...for now.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
To accomplish this, we add another VeilState which is called
LockedInherited. The idea is to apply exec unveil data, similar to
execpromises of the pledge syscall, on the current exec'ed program
during the execve sequence. When applying the forced unveil data, the
veil state is set to be locked but the special state of LockedInherited
ensures that if the new program tries to unveil paths, the request will
silently be ignored, so the program will continue running without
receiving an error, but is still can only use the paths that were
unveiled before the exec syscall. This in turn, allows us to use the
unveil syscall with a special utility to sandbox other userland programs
in terms of what is visible to them on the filesystem, and is usable on
both programs that use or don't use the unveil syscall in their code.
This happens in two ways:
1. LibCore now has two new methods for creating Jails and attaching
processes to a Jail.
2. We introduce 3 new utilities - lsjails, jail-create and jails-attach,
which list jails, create jails and attach processes to a Jail,
respectively.
This method was taken from the pls utility and its purpose is to execute
a given command with all the required requirements such as providing a
suitable exec environment.
We previously had at least three different implementations for resolving
executables in the PATH, all of which had slightly different
characteristics.
Merge those into a single implementation to keep the behaviour
consistent, and maybe to make that implementation more configurable in
the future.
Most changes are around user and group management, which are exposed in
the Android NDK differently than other Unices.
We require version 30 for memfd_create, version 28 for posix_spawn, and
so on. It's possible a shim for memfd_create could be used, but since
Google is mandating new apps use API level 30 as of Nov 2022, this seems
suitable.
These convenience templates allow the following to be written as before:
TRY(Core::System::pledge("promises..."));
TRY(Core::System::pledge("promises...", "execpromises..."));
TRY(Core::System::unveil("path", "permissions"));
TRY(Core::System::unveil(nullptr, nullptr));
Other uses must now append sv to any literal string passed to pledge and
unveil.
This is a single function, which behaves like the various LibC exec()
functions depending on the passed parameters. No direct equivalent is
made for execl() - you have to wrap your arguments in a Span of some
kind.
On Serenity, this calls the syscall directly, whereas Lagom forwards to
the appropriate LibC function.
In a few places we intentionally drop privileges to reduce the potential
security surface area of networked program, with the pattern of:
```
if (setgid(getgid()) || setuid(getuid()) {
return 1;
}
```
We can make this a bit nicer to use by creating a wrapper.
I also added a common interface with StringView compatible parameters:
int serenity_setenv(const char*, ssize_t, const char*, ssize_t, int)
This function is called by both C and C++ API for setenv().
This wrapper is particularly helpful as we use a combination of similar
syscalls on Linux to simulate the behavior of the Serenity-exclusive
anon_create syscall. Users therefore won't have to worry about the
platform anymore :^)
