beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 15:40:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Kernel/Syscalls/unveil.cpp

177 lines
7.5 KiB
C++
Raw Normal View History

Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
Kernel: Allow unveiling subfolders regardless of parent's permissions This fixes a bug where unveiling a subdirectory of an already unveiled path would sometimes be allowed and sometimes not (depending on what other unveil calls have been made). Now, it is always allowed to unveil a subdirectory of an already unveiled directory, even if it has higher permissions. This removes the need for the permissions_inherited_from_root flag in UnveilMetadata, so it has been removed.
2021-06-06 19:03:19 +00:00
* Copyright (c) 2021, Max Wipfli <mail@maxwipfli.ch>
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
*/
Kernel: Use RefPtr instead of LockRefPtr for Custody By protecting all the RefPtr<Custody> objects that may be accessed from multiple threads at the same time (with spinlocks), we remove the need for using LockRefPtr<Custody> (which is basically a RefPtr with a built-in spinlock.)
2022-08-20 23:04:35 +00:00
#include <AK/RefPtr.h>
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
#include <AK/StringView.h>
Kernel+LibCore+LibC: Implement support for forcing unveil on exec 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.
2022-11-04 17:20:11 +00:00
#include <Kernel/API/Unveil.h>
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
#include <Kernel/FileSystem/Custody.h>
#include <Kernel/FileSystem/VirtualFileSystem.h>
Kernel: Replace usage of LexicalPath with KLexicalPath This replaces all uses of LexicalPath in the Kernel with the functions from KLexicalPath. This also allows the Kernel to stop including AK::LexicalPath.
2021-07-06 09:21:52 +00:00
#include <Kernel/KLexicalPath.h>
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
#include <Kernel/Process.h>
namespace Kernel {
Kernel: Update intermediate nodes when changing unveil permissions When changing the unveil permissions of a preexisting node, we need to make sure that any intermediate nodes that were created before and should inherit permissions from the updated node are updated properly. This fixes the following bug: unveil("/home/anon/Documents", "r"); unveil("/home", "r"); Now there was a intermediate node for "/home/anon" which still had no permission, even though it should have inherited the permissions from "/home".
2021-06-06 20:12:04 +00:00
static void update_intermediate_node_permissions(UnveilNode& root_node, UnveilAccess new_permissions)
{
for (auto& entry : root_node.children()) {
auto& node = static_cast<UnveilNode&>(*entry.value);
if (node.was_explicitly_unveiled())
continue;
AK+Kernel: OOM-harden most parts of Trie The only part of Unveil that can't handle OOM gracefully is the String::formatted() use in the node metadata.
2022-02-14 13:19:53 +00:00
node.metadata_value().permissions = new_permissions;
Kernel: Update intermediate nodes when changing unveil permissions When changing the unveil permissions of a preexisting node, we need to make sure that any intermediate nodes that were created before and should inherit permissions from the updated node are updated properly. This fixes the following bug: unveil("/home/anon/Documents", "r"); unveil("/home", "r"); Now there was a intermediate node for "/home/anon" which still had no permission, even though it should have inherited the permissions from "/home".
2021-06-06 20:12:04 +00:00
update_intermediate_node_permissions(node, new_permissions);
}
}
Kernel+LibCore+LibC: Implement support for forcing unveil on exec 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.
2022-11-04 17:20:11 +00:00
static ErrorOr<void> update_unveil_data(Process::UnveilData& locked_unveil_data, StringView unveiled_path, UnveilAccess new_permissions)
{
auto path_parts = KLexicalPath::parts(unveiled_path);
auto it = path_parts.begin();
// Note: For the sake of completence, we check if the locked state was inherited
// by an execve'd sequence. If that is the case, just silently ignore this.
if (locked_unveil_data.state == VeilState::LockedInherited)
return {};
// NOTE: We have to check again, since the veil may have been locked by another thread
// while we were parsing the arguments.
if (locked_unveil_data.state == VeilState::Locked)
return EPERM;
auto& matching_node = locked_unveil_data.paths.traverse_until_last_accessible_node(it, path_parts.end());
if (it.is_end()) {
// If the path has already been explicitly unveiled, do not allow elevating its permissions.
if (matching_node.was_explicitly_unveiled()) {
if (new_permissions & ~matching_node.permissions())
return EPERM;
}
// It is possible that nodes that are "grandchildren" of the matching node have already been unveiled.
// This means that there may be intermediate nodes between this one and the unveiled "grandchildren"
// that inherited the current node's previous permissions. Those nodes now need their permissions
// updated to match the current node.
if (matching_node.permissions() != new_permissions)
update_intermediate_node_permissions(matching_node, new_permissions);
matching_node.metadata_value().explicitly_unveiled = true;
matching_node.metadata_value().permissions = new_permissions;
locked_unveil_data.state = VeilState::Dropped;
return {};
}
auto new_unveiled_path = TRY(KString::try_create(unveiled_path));
TRY(matching_node.insert(
it,
path_parts.end(),
{ move(new_unveiled_path), new_permissions, true },
[](auto& parent, auto& it) -> ErrorOr<Optional<UnveilMetadata>> {
auto path = TRY(KString::formatted("{}/{}", parent.path(), *it));
return UnveilMetadata(move(path), parent.permissions(), false);
}));
VERIFY(locked_unveil_data.state != VeilState::Locked);
locked_unveil_data.state = VeilState::Dropped;
return {};
}
Everywhere: Run clang-format
2022-04-01 17:58:27 +00:00
ErrorOr<FlatPtr> Process::sys$unveil(Userspace<Syscall::SC_unveil_params const*> user_params)
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
{
Kernel: Make sys$unveil() not take the big process lock The unveil syscall uses the UnveilData struct which is already SpinlockProtected, so there is no need to take the big lock.
2022-08-17 02:52:58 +00:00
VERIFY_NO_PROCESS_BIG_LOCK(this);
Kernel: Use copy_typed_from_user<T> for fetching syscall parameters
2021-09-05 15:51:37 +00:00
auto params = TRY(copy_typed_from_user(user_params));
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
if (!params.path.characters && !params.permissions.characters) {
Kernel: Put Process unveil state in a SpinlockProtected container This makes path resolution safe to perform without holding the big lock.
2022-03-07 20:23:08 +00:00
m_unveil_data.with([&](auto& unveil_data) { unveil_data.state = VeilState::Locked; });
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
return 0;
}
Kernel+LibCore+LibC: Implement support for forcing unveil on exec 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.
2022-11-04 17:20:11 +00:00
if (!((params.flags & to_underlying(UnveilFlags::CurrentProgram)) || (params.flags & to_underlying(UnveilFlags::AfterExec))))
return EINVAL;
// Note: If we inherited a locked state, then silently ignore the unveil request,
// and let the user program potentially deal with an ENOENT error later on.
if ((params.flags & static_cast<unsigned>(UnveilFlags::CurrentProgram)) && veil_state() == VeilState::LockedInherited)
return 0;
// Note: We only lock the unveil state for current program, while allowing adding
// indefinitely unveil data before doing the actual exec().
if ((params.flags & static_cast<unsigned>(UnveilFlags::CurrentProgram)) && veil_state() == VeilState::Locked)
Kernel: Make all syscall functions return KResultOr<T> This makes it a lot easier to return errors since we no longer have to worry about negating EFOO errors and can just return them flat.
2021-03-01 12:49:16 +00:00
return EPERM;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
if (!params.path.characters || !params.permissions.characters)
Kernel: Make all syscall functions return KResultOr<T> This makes it a lot easier to return errors since we no longer have to worry about negating EFOO errors and can just return them flat.
2021-03-01 12:49:16 +00:00
return EINVAL;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
Kernel: Add unveil('b') This is a new "browse" permission that lets you open (and subsequently list contents of) directories underneath the path, but not regular files or any other types of files.
2020-11-21 19:55:20 +00:00
if (params.permissions.length > 5)
Kernel: Make all syscall functions return KResultOr<T> This makes it a lot easier to return errors since we no longer have to worry about negating EFOO errors and can just return them flat.
2021-03-01 12:49:16 +00:00
return EINVAL;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
Kernel: Use TRY() in sys$unveil()
2021-09-05 12:30:08 +00:00
auto path = TRY(get_syscall_path_argument(params.path));
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
Kernel: Use TRY() in sys$unveil()
2021-09-05 12:30:08 +00:00
if (path->is_empty() || !path->view().starts_with('/'))
Kernel: Make all syscall functions return KResultOr<T> This makes it a lot easier to return errors since we no longer have to worry about negating EFOO errors and can just return them flat.
2021-03-01 12:49:16 +00:00
return EINVAL;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
Kernel: Use TRY() in sys$unveil()
2021-09-05 12:30:08 +00:00
auto permissions = TRY(try_copy_kstring_from_user(params.permissions));
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
Kernel: Prevent `unveil` returning ENOENT with cpath permissions This addresses the issue first enountered in #3644. If a path is first unveiled with "c" permissions, we should NOT return ENOENT if the node does not exist on the disk, as the program will most likely be creating it at a later time.
2020-11-05 07:12:23 +00:00
// Let's work out permissions first...
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
unsigned new_permissions = 0;
Everywhere: Run clang-format
2022-04-01 17:58:27 +00:00
for (char const permission : permissions->view()) {
Kernel: Use for-each loops in unveil syscall
2020-08-02 19:06:39 +00:00
switch (permission) {
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
case 'r':
Kernel: Implement unveil() as a prefix-tree Fixes #4530.
2020-12-26 10:24:34 +00:00
new_permissions |= UnveilAccess::Read;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
break;
case 'w':
Kernel: Implement unveil() as a prefix-tree Fixes #4530.
2020-12-26 10:24:34 +00:00
new_permissions |= UnveilAccess::Write;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
break;
case 'x':
Kernel: Implement unveil() as a prefix-tree Fixes #4530.
2020-12-26 10:24:34 +00:00
new_permissions |= UnveilAccess::Execute;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
break;
case 'c':
Kernel: Implement unveil() as a prefix-tree Fixes #4530.
2020-12-26 10:24:34 +00:00
new_permissions |= UnveilAccess::CreateOrRemove;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
break;
Kernel: Add unveil('b') This is a new "browse" permission that lets you open (and subsequently list contents of) directories underneath the path, but not regular files or any other types of files.
2020-11-21 19:55:20 +00:00
case 'b':
Kernel: Implement unveil() as a prefix-tree Fixes #4530.
2020-12-26 10:24:34 +00:00
new_permissions |= UnveilAccess::Browse;
Kernel: Add unveil('b') This is a new "browse" permission that lets you open (and subsequently list contents of) directories underneath the path, but not regular files or any other types of files.
2020-11-21 19:55:20 +00:00
break;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
default:
Kernel: Make all syscall functions return KResultOr<T> This makes it a lot easier to return errors since we no longer have to worry about negating EFOO errors and can just return them flat.
2021-03-01 12:49:16 +00:00
return EINVAL;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
}
}
Kernel: Prevent `unveil` returning ENOENT with cpath permissions This addresses the issue first enountered in #3644. If a path is first unveiled with "c" permissions, we should NOT return ENOENT if the node does not exist on the disk, as the program will most likely be creating it at a later time.
2020-11-05 07:12:23 +00:00
// Now, let's try and resolve the path and obtain custody of the inode on the disk, and if not, bail out with
// the error from resolve_path_without_veil()
// However, if the user specified unveil() with "c" permissions, we don't set errno if ENOENT is encountered,
// because they most likely intend the program to create the file for them later on.
// If this case is encountered, the parent node of the path is returned and the custody of that inode is used instead.
Kernel: Use RefPtr instead of LockRefPtr for Custody By protecting all the RefPtr<Custody> objects that may be accessed from multiple threads at the same time (with spinlocks), we remove the need for using LockRefPtr<Custody> (which is basically a RefPtr with a built-in spinlock.)
2022-08-20 23:04:35 +00:00
RefPtr<Custody> parent_custody; // Parent inode in case of ENOENT
Kernel: Custody::absolute_path() => try_create_absolute_path() This converts most users of Custody::absolute_path() to use the new try_create_absolute_path() API, and return ENOMEM if the KString allocation fails.
2021-07-06 10:58:03 +00:00
OwnPtr<KString> new_unveiled_path;
Kernel: Make VirtualFileSystem functions take credentials as input Instead of getting credentials from Process::current(), we now require that they be provided as input to the various VFS functions. This ensures that an atomic set of credentials is used throughout an entire VFS operation.
2022-08-21 14:02:24 +00:00
auto custody_or_error = VirtualFileSystem::the().resolve_path_without_veil(credentials(), path->view(), VirtualFileSystem::the().root_custody(), &parent_custody);
Kernel: Prevent `unveil` returning ENOENT with cpath permissions This addresses the issue first enountered in #3644. If a path is first unveiled with "c" permissions, we should NOT return ENOENT if the node does not exist on the disk, as the program will most likely be creating it at a later time.
2020-11-05 07:12:23 +00:00
if (!custody_or_error.is_error()) {
Kernel: Improvements to Custody absolute path serialization - Renamed try_create_absolute_path() => try_serialize_absolute_path() - Use KResultOr and TRY() to propagate errors - Don't call this when it's only for debug logging
2021-09-06 10:24:36 +00:00
new_unveiled_path = TRY(custody_or_error.value()->try_serialize_absolute_path());
Kernel: Replace KResult and KResultOr<T> with Error and ErrorOr<T> We now use AK::Error and AK::ErrorOr<T> in both kernel and userspace! This was a slightly tedious refactoring that took a long time, so it's not unlikely that some bugs crept in. Nevertheless, it does pass basic functionality testing, and it's just real nice to finally see the same pattern in all contexts. :^)
2021-11-07 23:51:39 +00:00
} else if (custody_or_error.error().code() == ENOENT && parent_custody && (new_permissions & UnveilAccess::CreateOrRemove)) {
Kernel: Improvements to Custody absolute path serialization - Renamed try_create_absolute_path() => try_serialize_absolute_path() - Use KResultOr and TRY() to propagate errors - Don't call this when it's only for debug logging
2021-09-06 10:24:36 +00:00
auto parent_custody_path = TRY(parent_custody->try_serialize_absolute_path());
Kernel: Make KString factories return KResultOr + use TRY() everywhere There are a number of places that don't have an error propagation path right now, so I've added FIXME's about that.
2021-09-06 17:24:54 +00:00
new_unveiled_path = TRY(KLexicalPath::try_join(parent_custody_path->view(), KLexicalPath::basename(path->view())));
Kernel: Prevent `unveil` returning ENOENT with cpath permissions This addresses the issue first enountered in #3644. If a path is first unveiled with "c" permissions, we should NOT return ENOENT if the node does not exist on the disk, as the program will most likely be creating it at a later time.
2020-11-05 07:12:23 +00:00
} else {
// FIXME Should this be EINVAL?
Kernel: Replace KResult and KResultOr<T> with Error and ErrorOr<T> We now use AK::Error and AK::ErrorOr<T> in both kernel and userspace! This was a slightly tedious refactoring that took a long time, so it's not unlikely that some bugs crept in. Nevertheless, it does pass basic functionality testing, and it's just real nice to finally see the same pattern in all contexts. :^)
2021-11-07 23:51:39 +00:00
return custody_or_error.release_error();
Kernel: Prevent `unveil` returning ENOENT with cpath permissions This addresses the issue first enountered in #3644. If a path is first unveiled with "c" permissions, we should NOT return ENOENT if the node does not exist on the disk, as the program will most likely be creating it at a later time.
2020-11-05 07:12:23 +00:00
}
Kernel+LibCore+LibC: Implement support for forcing unveil on exec 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.
2022-11-04 17:20:11 +00:00
if (params.flags & static_cast<unsigned>(UnveilFlags::CurrentProgram)) {
TRY(unveil_data().with([&](auto& data) -> ErrorOr<void> {
TRY(update_unveil_data(data, new_unveiled_path->view(), static_cast<UnveilAccess>(new_permissions)));
return {};
}));
}
Kernel: Update intermediate nodes when changing unveil permissions When changing the unveil permissions of a preexisting node, we need to make sure that any intermediate nodes that were created before and should inherit permissions from the updated node are updated properly. This fixes the following bug: unveil("/home/anon/Documents", "r"); unveil("/home", "r"); Now there was a intermediate node for "/home/anon" which still had no permission, even though it should have inherited the permissions from "/home".
2021-06-06 20:12:04 +00:00
Kernel+LibCore+LibC: Implement support for forcing unveil on exec 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.
2022-11-04 17:20:11 +00:00
if (params.flags & static_cast<unsigned>(UnveilFlags::AfterExec)) {
TRY(exec_unveil_data().with([&](auto& data) -> ErrorOr<void> {
// Note: The only valid way to get into this state is by using unveil before doing
// an actual exec with the UnveilFlags::AfterExec flag. Then this state is applied on
// the actual new program unveil data, and never on the m_exec_unveil_data.
VERIFY(data.state != VeilState::LockedInherited);
TRY(update_unveil_data(data, new_unveiled_path->view(), static_cast<UnveilAccess>(new_permissions)));
return {};
}));
}
return 0;
Kernel: Move syscall implementations out of Process.cpp This is something I've been meaning to do for a long time, and here we finally go. This patch moves all sys$foo functions out of Process.cpp and into files in Kernel/Syscalls/. It's not exactly one syscall per file (although it could be, but I got a bit tired of the repetitive work here..) This makes hacking on individual syscalls a lot less painful since you don't have to rebuild nearly as much code every time. I'm also hopeful that this makes it easier to understand individual syscalls. :^)
2020-07-30 21:38:15 +00:00
}
}
Reference in a new issue Copy permalink