The "stay_within" parameter to CObject::dispatch_event() optionally
specifies a node in the CObject parent chain where event dispatch
should stop bubbling upwards.
Since event dispatch is done recursively, this was not working right,
as we would simply return from the innermost dispatch loop, leaving
the event un-accepted, which meant that the penultimately inner
dispatch loop would pick up the event and keep bubbling it anyway.
This made it possible for events to jump across window boundaries
within an application, in cases where one window was a CObject ancestor
of another window. This is typically the case with dialog windows.
Fix#1078.
A process has one of three veil states:
- None: unveil() has never been called.
- Dropped: unveil() has been called, and can be called again.
- Locked: unveil() has been called, and cannot be called again.
Sergey suggested that having a non-zero O_RDONLY would make some things
less confusing, and it seems like he's right about that.
We can now easily check read/write permissions separately instead of
dancing around with the bits.
This patch also fixes unveil() validation for O_RDWR which previously
forgot to check for "r" permission.
This syscall is a complement to pledge() and adds the same sort of
incremental relinquishing of capabilities for filesystem access.
The first call to unveil() will "drop a veil" on the process, and from
now on, only unveiled parts of the filesystem are visible to it.
Each call to unveil() specifies a path to either a directory or a file
along with permissions for that path. The permissions are a combination
of the following:
- r: Read access (like the "rpath" promise)
- w: Write access (like the "wpath" promise)
- x: Execute access
- c: Create/remove access (like the "cpath" promise)
Attempts to open a path that has not been unveiled with fail with
ENOENT. If the unveiled path lacks sufficient permissions, it will fail
with EACCES.
Like pledge(), subsequent calls to unveil() with the same path can only
remove permissions, not add them.
Once you call unveil(nullptr, nullptr), the veil is locked, and it's no
longer possible to unveil any more paths for the process, ever.
This concept comes from OpenBSD, and their implementation does various
things differently, I'm sure. This is just a first implementation for
SerenityOS, and we'll keep improving on it as we go. :^)
Currently the points of a triangle do not need to be initialised in a
certain orientation. Currently, the only real method in the class is
`contains`. However we can continue extending the class if and when we
need more functionality.
As suggested by Joshua, this commit adds the 2-clause BSD license as a
comment block to the top of every source file.
For the first pass, I've just added myself for simplicity. I encourage
everyone to add themselves as copyright holders of any file they've
added or modified in some significant way. If I've added myself in
error somewhere, feel free to replace it with the appropriate copyright
holder instead.
Going forward, all new source files should include a license header.
I kept on trying to use the enter key to navigate a tree view, when only
left and right arrow keys are used for this. Now also suport the return
key, is used as a toggle to open a tree.
It used to only read the data it could get without blocking. Andreas says this
was intentional, but it's counterintuitive and no code that uses read_all()
actually expects it to return only a part of the data. So change it to always
read data until an EOF (or an error) is received.
The syscall is now called sys$open(), but it behaves like the old sys$openat().
In userspace, open_with_path_length() is made a wrapper over openat_with_path_length().
It was possible to craft a custom ELF executable that when symbolicated
would cause the kernel to read from user-controlled addresses anywhere
in memory. You could then fetch this memory via /proc/PID/stack
We fix this by making ELFImage hand out StringView rather than raw
const char* for symbol names. In case a symbol offset is outside the
ELF image, you get a null StringView. :^)
Test: Kernel/elf-symbolication-kernel-read-exploit.cpp
When the new font is a different size, just use that font for bold
glyphs as well. It would be nice to find a matching bold version of
the new font automatically in the future.
Add "Link", "ActiveLink" and "VisitedLink" colors to the system theme
definition, and implement support for them in LibHTML.
Note that <body link="foo" alink="bar" vlink="baz"> takes precedence
over the system colors. Author style also takes precedence, since we
only fetch the system color in case the CSS color is -libhtml-link.
CArgsParser::parse_next_param did not properly ensure that, when
a param required a following argument, there were enough parameters left to
complete the parse. This meant that params_left could become negative,
avoiding parse_next_param's termination condition, and cause a segfault
when reading from argv with an out of bounds index.
This fixes the check to ensure that we do in fact have the right amount
of parameters and also adds an assertion to ensure that params_left does
not become negative.
These will make sure there's no funny business or funny offsets in the
main ELF header or each Program Header. More can still be done (like
validating section headers), but this is a good start
Since a chroot is in many ways similar to a separate root mount, we can also
apply mount flags to it as if it was an actual mount. These flags will apply
whenever the chrooted process accesses its root directory, but not when other
processes access this same directory for the outside. Since it's common to
chdir("/") immediately after chrooting (so that files accessed through the
current directory inherit the same mount flags), this effectively allows one to
apply additional limitations to a process confined inside a chroot.
To this effect, sys$chroot() gains a mount_flags argument (exposed as
chroot_with_mount_flags() in userspace) which can be set to all the same values
as the flags argument for sys$mount(), and additionally to -1 to keep the flags
set for that file system. Note that passing 0 as mount_flags will unset any
flags that may have been set for the file system, not keep them.
This patch adds a new replace widget that cooperates with the find
widget, the replace widget takes the input in the find textbox, searches
for occurences of that input, and replaces them with the input provied
in the replace textbox.
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.
If we pass a null path to these syscall wrappers, just return EFAULT
directly from the wrapper instead of segfaulting by calling strlen().
This is a compromise, since we now have to pass the path length to the
kernel, so we can't rely on the kernel to tell us that the path is at
a bad memory address.
I though it would be nice to also show the style that the browser uses
to display an element.
In order to do that, in place of the styles table I've put a tab widget,
with tabs for both element and computed element styles.
