Add fchroot(2)
Needs ReviewPublic
Actions

Authored by trasz on Aug 23 2023, 2:07 PM.

Details

Reviewers

brooks

Group Reviewers

capsicum

Summary

This is similar to chroot(2), but takes a file descriptor instead
of path. A similar syscall exists in NetBSD. It is part of a larger
patch to make absolute pathnames usable in Capsicum mode, but should
be useful in other contexts too.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 57538
Build 54426: arc lint + arc unit

Event Timeline

trasz created this revision.Aug 23 2023, 2:07 PM

Herald added a reviewer: brooks. · View Herald TranscriptAug 23 2023, 2:07 PM

Herald added a subscriber: imp. · View Herald Transcript

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

Harbormaster completed remote builds in B53254: Diff 126417.Aug 23 2023, 2:07 PM

trasz mentioned this in D38351: [RFC/Proposal] Mechanism for in-kernel AT_FDCWD substitution with provided FD for oblivious sandboxing with Capsicum.Aug 23 2023, 2:08 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
1032	Need a `struct fchroot_args` definition. for consistency with the rest of the file.
usr.sbin/chroot/chroot.8
58–60 ↗	(On Diff #126417)

In D41564#950112, @brooks wrote:

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.

Update.

Herald added a subscriber: olce. · View Herald TranscriptWed, May 1, 7:50 AM

Harbormaster completed remote builds in B57484: Diff 137925.Wed, May 1, 7:50 AM

trasz retitled this revision from Add fchroot(2) and chroot -d to Add fchroot(2).Wed, May 1, 7:53 AM

trasz edited the summary of this revision. (Show Details)

trasz marked an inline comment as done.

As for CAP_FCHROOT - I think we should have it, if only for symmetry with CAP_FCHDIR. I don't really want to implement them - the lookup code isn't really suited for tracking rights for root and cwd, and so those two syscalls require full rights to succeed, not just a subset - but we could in the future.

trasz added a reviewer: capsicum.Wed, May 1, 10:39 AM

Add back procstat(1) bits and remove syscalls.map

Harbormaster completed remote builds in B57493: Diff 137939.Wed, May 1, 10:49 AM

trasz edited the summary of this revision. (Show Details)Wed, May 1, 6:17 PM

brooks added inline comments.Wed, May 1, 8:36 PM

lib/libsys/Symbol.sys.map
371	Should be FBSD_1.8
lib/libsys/chroot.2
33	Are multiple .Nm's valid?

Use the right symbol version and bump Dd.

Harbormaster completed remote builds in B57538: Diff 138006.Thu, May 2, 7:08 AM

trasz marked an inline comment as done.Thu, May 2, 7:12 AM

trasz added inline comments.

lib/libsys/Symbol.sys.map
383	Btw, the entry for kcmp seems misaligned compared to syscalls in sections above.
lib/libsys/chroot.2
33	I think so, that's what eg chdir.2 or chmod.2 do. Although this made me realize I forgot to bump the date.