Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

open: add Open(at)InRoot and Reopen #15

Merged
merged 5 commits into from
Jul 11, 2024
Merged

open: add Open(at)InRoot and Reopen #15

merged 5 commits into from
Jul 11, 2024

Conversation

cyphar
Copy link
Owner

@cyphar cyphar commented Jul 10, 2024

These are very thin wrappers around the existing partialLookupInRoot and
doProcSelfMagiclink infrastructure to allow user to get a much safer API
for operating on paths than SecureJoin. In principle, with very careful
usage, these operations should be sufficient to make any program safe
against races.

In theory we could disable the symlink stack when doing OpenInRoot
(because the symlink stack is only relevant for partial lookups), but
for now we'll just keep the codepaths the same. Also, add a note to
SecureJoin to tell users that you should probably use OpenInRoot if you
can.

This API is based on the libpathrs base API.

Closes #12
Signed-off-by: Aleksa Sarai cyphar@cyphar.com

In order to add a reopen primitive, it'll be necessary to do very
similar checks to procSelfFdReadlink but with slightly different types.
By refactoring procSelfFdReadlink with generics we can use the same
codepath for both operations.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These are very thin wrappers around the existing partialLookupInRoot and
doProcSelfMagiclink infrastructure to allow user to get a much safer API
for operating on paths than SecureJoin. In principle, with very careful
usage, these operations should be sufficient to make any program safe
against races.

In theory we could disable the symlink stack when doing OpenInRoot
(because the symlink stack is only relevant for partial lookups), but
for now we'll just keep the codepaths the same. Also, add a note to
SecureJoin to tell users that you should probably use OpenInRoot if you
can.

This API is based on the libpathrs base API.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These are mostly based on the partialOpen tests, but making sure we
don't return any partial resolutions.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
We need to read the list of dirents during the loop, and re-opening and
closing the fd each time doesn't really make much sense. O_DIRECTORY
should stop us from opening any "bad" inodes, so we might as well make
MkdirAllHandle always return an O_DIRECTORY and we can eliminate all of
the unneeded reopens.

We need to duplicate the handle at the start to make sure we return a
non-O_PATH even if we are asked to MkdirAll an existing directory. We
can just re-use Reopen now that we have it.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
@cyphar cyphar merged commit 6ae6d58 into main Jul 11, 2024
12 checks passed
@cyphar cyphar deleted the open-in-root branch July 11, 2024 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide examples how to do os.OpenFile securely after SecureJoin()
1 participant