While fd created from this side always has the FD_CLOEXEC flag, the same is not true for files left open by the parent. This change prevents those files from leaking into the container.
Signed-off-by: Ophestra <cat@gensokyo.uk>
This leaves slots available for additional uid ranges in Rosa OS.
This breaks all existing installations! Users are required to fix ownership manually.
Closes#18.
Signed-off-by: Ophestra <cat@gensokyo.uk>
Since this is going to be placed in a shared directory, it needs to be unique to the identity. Instead of trying to figure out identity from mountinfo, just have the test script pass hardcoded values.
Signed-off-by: Ophestra <cat@gensokyo.uk>
The privileged user is identifier to hakurei through its hsu userid. Using the kernel uid here makes little sense and is a leftover design choice from before hsu was implemented.
Closes#7.
Signed-off-by: Ophestra <cat@gensokyo.uk>
There is no reason to give the home directory special treatment, as this behaviour can be quite confusing. The home directory also does not necessarily require its own mount point, it could be provided by a parent or simply be ephemeral.
Signed-off-by: Ophestra <cat@gensokyo.uk>
This is the first hakurei run in the test, if the container outright fails to start this is often where it happens, so throwing away the output is very unhelpful.
Signed-off-by: Ophestra <cat@gensokyo.uk>
The socket is typically owned by the priv-user, and inaccessible by the target user, so just allowing access to the directory is not enough. This change fixes this oversight and add checks that will also be useful for merging security/hakurei#1.
Signed-off-by: Ophestra <cat@gensokyo.uk>
There is usually no good reason to write to /dev. This however doesn't work in internal/app because FilesystemConfig supplied by ContainerConfig might add entries to /dev, so internal/app follows DevWritable with Remount instead.
Signed-off-by: Ophestra <cat@gensokyo.uk>
This does nothing for security, but should help avoid hiding bugs of programs developed in a hakurei container.
Signed-off-by: Ophestra <cat@gensokyo.uk>
Doing this instead of mounting directly on / because it's impossible to ensure a parent is available for every path hakurei wants to mount to. This situation is similar to autoetc hence the similar name, however a symlink mirror will not work in this case.
Signed-off-by: Ophestra <cat@gensokyo.uk>
This syscall is not wired on all platforms. This test barely does anything anyway and seccomp is covered by the privileged test instrumentation.
Signed-off-by: Ophestra <cat@gensokyo.uk>
