Page MenuHomeFreeBSD

Add fchroot(2)
ClosedPublic

Authored by trasz on Aug 23 2023, 2:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jan 10, 11:06 PM
Unknown Object (File)
Fri, Jan 10, 11:06 PM
Unknown Object (File)
Fri, Jan 10, 10:29 PM
Unknown Object (File)
Tue, Jan 7, 11:42 AM
Unknown Object (File)
Thu, Jan 2, 1:08 PM
Unknown Object (File)
Fri, Dec 20, 7:54 PM
Unknown Object (File)
Dec 14 2024, 11:01 PM
Unknown Object (File)
Dec 9 2024, 8:26 PM
Subscribers

Details

Reviewers
brooks
Group Reviewers
capsicum
Commits
rGb165e9e3ea4e: Add fchroot(2)
Summary

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

Sponsored by: Innovate UK

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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
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)

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.

trasz retitled this revision from Add fchroot(2) and chroot -d to Add fchroot(2).May 1 2024, 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 edited the summary of this revision. (Show Details)

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

lib/libsys/Symbol.sys.map
370

Should be FBSD_1.8

lib/libsys/chroot.2
33

Are multiple .Nm's valid?

Use the right symbol version and bump Dd.

trasz marked an inline comment as done.May 2 2024, 7:12 AM
trasz added inline comments.
lib/libsys/Symbol.sys.map
382–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.

lib/libsys/chroot.2
101
sys/kern/syscalls.master
3344

Do you want to mark this CAPENABLED? It seems generally safe if pointless without the changes in D44373.

trasz added inline comments.
sys/kern/syscalls.master
3344

I think I'd prefer to to it later, together with fchdir(2).

So... how do we proceed with this?

A few more nits to address.

include/unistd.h
472

This is the wrong place. fchroot isn't part of XSI

lib/libsys/Symbol.sys.map
382–383

I've fixed this whitespace bug

lib/libsys/chroot.2
106

Presumably fchroot needs it's own error section with at least EBADF

sys/kern/syscalls.master
3346
trasz marked 2 inline comments as done.

Some more fixes from Brooks.

This revision is now accepted and ready to land.Sep 14 2024, 5:18 PM
This revision was automatically updated to reflect the committed changes.