This patch implements basic support for OpenBSD-style pledge().
pledge() allows programs to incrementally reduce their set of allowed
syscalls, which are divided into categories that each make up a subset
of POSIX functionality.
If a process violates one of its pledged promises by attempting to call
a syscall that it previously said it wouldn't call, the process is
immediately terminated with an uncatchable SIGABRT.
This is by no means complete, and we'll need to add more checks in
various places to ensure that promises are being kept.
But it is pretty cool! :^)
We now support these mount flags:
* MS_NODEV: disallow opening any devices from this file system
* MS_NOEXEC: disallow executing any executables from this file system
* MS_NOSUID: ignore set-user-id bits on executables from this file system
The fourth flag, MS_BIND, is defined, but currently ignored.
O_EXEC is mentioned by POSIX, so let's have it. Currently, it is only used
inside the kernel to ensure the process has the right permissions when opening
an executable.
At the moment, the actual flags are ignored, but we correctly propagate them all
the way from the original mount() syscall to each custody that resides on the
mounted FS.
Other implementations of pthread_setname_np() do not take the name
length as an argument.
For pthread_getname_np(), other implementations take the buffer size
as a size_t.
This patch brings us in line with other implementations.
While I was updating syscalls to stop passing null-terminated strings,
I added some helpful struct types:
- StringArgument { const char*; size_t; }
- ImmutableBuffer<Data, Size> { const Data*; Size; }
- MutableBuffer<Data, Size> { Data*; Size; }
The Process class has some convenience functions for validating and
optionally extracting the contents from these structs:
- get_syscall_path_argument(StringArgument)
- validate_and_copy_string_from_user(StringArgument)
- validate(ImmutableBuffer)
- validate(MutableBuffer)
There's still so much code around this and I'm wondering if we should
generate most of it instead. Possible nice little project.
The chroot() syscall now allows the superuser to isolate a process into
a specific subtree of the filesystem. This is not strictly permanent,
as it is also possible for a superuser to break *out* of a chroot, but
it is a useful mechanism for isolating unprivileged processes.
The VFS now uses the current process's root_directory() as the root for
path resolution purposes. The root directory is stored as an uncached
Custody in the Process object.
Note that I'm developing some helper types in the Syscall namespace as
I go here. Once I settle on some nice types, I will convert all the
other syscalls to use them as well.
This is a shiny new widget that can display a tree using Miller columns ^:)
In many cases, the columns view can be used as an alternative to tree view,
but it has its own set of limitations:
* It can only display one model column (so it cannot replace a table)
* It takes up a lot of horizontal space, so it's only suitable if the item text
is fairly short
* It can only display one subtree at a time
But as long as a usecase doesn't suffer from these limitations, a columns view
can be *much* more intuitive than a tree view.
We used to have two different models for displaying file system contents:
the FileManager-grade table-like directory model, which exposed rich data
(such as file icons with integrated image previews) about contents of a
single directory, and the tree-like GFileSystemModel, which only exposed
a tree of file names with very basic info about them.
This commit unifies the two. The new GFileSystemModel can be used both as a
tree-like and as a table-like model, or in fact in both ways simultaneously.
It exposes rich data about a file system subtree rooted at the given root.
The users of the two previous models are all ported to use this new model.
The userspace execve() wrapper now measures all the strings and puts
them in a neat and tidy structure on the stack.
This way we know exactly how much to copy in the kernel, and we don't
have to use the SMAP-violating validate_read_str(). :^)
When loading a new executable, we now map the ELF image in kernel-only
memory and parse it there. Then we use copy_to_user() when initializing
writable regions with data from the executable.
Note that the exec() syscall still disables SMAP protection and will
require additional work. This patch only affects kernel-originated
process spawns.
Since ELFDynamicObject needs the actual virtual address of the .dynamic
section in the loaded image, and not the file offset like we assumed
before, due to MAP_PRIVATE secretly giving us a MAP_SHARED, we can
remove all of the Dynamic* code from ELFImage.
ELFDynamicLoader only needs ELFImage to get the Program headers at this
point. More consolidation opportunities seem likely in the future.
We need to workaround the fact that MAP_PRIVATE when passed a file
descriptor doesn't work the way we expect. We can't change the
permissions on our mmap to PROT_WRITE if the original executable doesn't
have PROT_WRITE.
Because of this, we need to construct our ELFDynamicObject using the
actual virtual address of the .dynamic section, instead of using the
offset into the ELFImage that was actually getting modified by accident
...somehow. Not clear what was going on.
We were not recomputing the internal dimensions after a font changed,
which caused things to look very off.
It's still not perfect as we're always using the same (small) font for
bold text, which obviously sticks out like a sore pinky when the rest
of the terminal text is large.
Previously if more than one item was selected clicking on one of
them and dragging would de-select everything that is not the one that
was clicked on. Now, if more than one items are selected and there
is a mousedown it goes into a "mightdrag" state.
The user can then perform a drag, if they don't everything that is not
the item being clicked gets unselected in the mouseup event, mimicking
the previous behavior.
Before this, you could make the kernel copy memory from anywhere by
setting up an ELF executable with a program header specifying file
offsets outside the file.
Since ELFImage didn't even know how large it was, we had no clue that
we were copying things from outside the ELF.
Fix this by adding a size field to ELFImage and validating program
header ranges before memcpy()'ing to them.
The ELF code is definitely going to need more validation and checking.
