Page MenuHomeFreeBSD

Add fchroot(2) and chroot -d
Needs ReviewPublic

Authored by trasz on Aug 23 2023, 2:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 19 2023, 11:20 PM
Unknown Object (File)
Dec 18 2023, 12:06 PM
Unknown Object (File)
Dec 13 2023, 5:19 AM
Unknown Object (File)
Dec 2 2023, 2:52 PM
Unknown Object (File)
Sep 30 2023, 7:19 PM
Unknown Object (File)
Sep 29 2023, 3:59 AM
Unknown Object (File)
Sep 21 2023, 10:27 PM
Unknown Object (File)
Sep 5 2023, 10:27 PM
Subscribers

Details

Reviewers
brooks
Summary

This adds a new system call, fchroot(2). The idea is to use it
with Capsicum for oblivious sandboxing, but for now it's just
a chroot(2) that takes a fd instead of path.

This also modifies chroot(8) utility to add "-d", so one can
do eg "chroot -nd 5 /bin/bash 5< /compat/jammy".

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 53254
Build 50145: arc lint + arc unit

Event Timeline

trasz requested review of this revision.Aug 23 2023, 2:07 PM

I wonder if a chrootat(fd, path) that allows a NULL path would be more general?

Should there be a flags argument?

We do need to spend a capability bit on this?

I'm skeptical of the chroot(8) change. I don't see how it's useful in practice. If committed it should be separate from the syscall addition.

sys/kern/vfs_syscalls.c
1033

Need a struct fchroot_args definition. for consistency with the rest of the file.

usr.sbin/chroot/chroot.8
58–60

I wonder if a chrootat(fd, path) that allows a NULL path would be more general?

Should there be a flags argument?

I'm not sure if I want to semantically mix "make this fd the new root" and "look up this path" bits. As it is now, it mimics fchdir(2). It's also compatible with NetBSD.

We do need to spend a capability bit on this?

Excellent question. I have no idea - my guess would be no, but because there already is CAP_FCHDIR, the purpose of which is also unclear to me, I simply followed suit.

I'm skeptical of the chroot(8) change. I don't see how it's useful in practice. If committed it should be separate from the syscall addition.

Agree - as it is now, it's mostly so that I can test the syscall by hand. Might become more useful in the future.