Date: Mon, 8 Jun 2026 12:06:54 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: Mark Johnston <markj@freebsd.org> Cc: Mariusz Zaborski <oshogbo@freebsd.org>, "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org>, freebsd-arch@freebsd.org, pjd@freebsd.org Subject: Re: rights(4) split? CAP_WRITE -> CAP_WRITE_DATA + CAP_WRITE_CTRL Message-ID: <6d1d90b8-432a-4202-8d63-eb752913e315@FreeBSD.org> In-Reply-To: <aiCSo77RM5qjMaUx@nuc> References: <7f5f2137-bd4d-4e27-8049-cf585849103e@FreeBSD.org> <CAGOYWV-FhQ_ZMQW0KwE2iZ_%2BOzLwU8VQ9FXZa06W4-tc7tQd-w@mail.gmail.com> <4feb230b-635e-4eca-8d9e-f89df2ad1377@FreeBSD.org> <aiCSo77RM5qjMaUx@nuc>
index | next in thread | previous in thread | raw e-mail
On 6/3/26 15:46, Mark Johnston wrote: > On Wed, Jun 03, 2026 at 09:15:11AM -0500, Kyle Evans wrote: >> On 6/3/26 03:04, Mariusz Zaborski wrote: >>> Hello, >>> >>> I think the idea of splitting CAP_WRITE into CAP_WRITE_DATA and CAP_WRITE_CTRL makes sense, especially for cases where a process should be able to exchange data but not transfer file descriptors. >>> >>> From my perspective, the biggest concern is the capability change itself. While source compatibility can largely be preserved by making CAP_WRITE an alias for CAP_WRITE_DATA | CAP_WRITE_CTRL, there is still some potential for compatibility issues with existing applications and binaries that rely on the current semantics of CAP_WRITE. >>> >> >> My alternative proposal would be that we slice off two entirely new bits in index 1 and still make `CAP_WRITE` an alias, but rename the current assignment to `CAP_WRITE_COMPAT`. We don't have any precedent for it, but I'd then handle translation at the cap_rights_*(2) border and unset the new `CAP_WRITE` if `CAP_WRITE_COMPAT` is unset when limiting, and unset `CAP_WRITE_LEGACY` if *either* of the new `CAP_WRITE_*` rights are missing. > Hi, Thought I responded to you, but it looks like I just internalized some of your ideas and responded to someone else referencing them. *sigh* > Just a couple of comments: > - Why CAP_WRITE_* instead of CAP_SEND_*? CAP_WRITE and CAP_SEND are > aliased today, but now that you're introducing rights specific to > sockets, CAP_SEND_* seems clearer. I hadn't considered that perspective- presumably it doesn't change the underlying semantics and CAP_WRITE/CAP_SEND still grant both of the CAP_SEND_* rights? That seems fine... I note that CAP_PWRITE and CAP_MMAP_W are interesting cases that include CAP_WRITE: these could be scoped down to CAP_SEND_DATA with the new model, but I don't think that's a problem to try and do- just a case that would need to be documented and well-communicate, in case anyone needed a full CAP_SEND. I suspect that's not the case, since you're not mmap()ing a socket, at least... pwrite(2) is probably a different story. > - Rather than allocating new bits, maybe we should consider repurposing > some indices which are only used with other file types? For instance, > CAP_PDKILL can only ever apply to procdescs, CAP_INOTIFY_* only apply > to inotify descriptors, etc.. There are still a fair number of bits > left, but it wouldn't be too hard to run out of them. Is there some > reason we can't define aliased rights? > I think that's fine, too, we just need to be really clear that we're making assumptions about these file types not growing write(2) semantics, for instance. I'm not sure we can do it for these ones in particular, though, because we need them to be combinable with for CAP_PWRITE and CAP_MMAP_W. While looking at CAP_PWRITE and CAP_MMAP_W, I realized there was a huge gap between CAP_ALL0 and CAP_UNUSED0*... I posted a change to clean up our representation of the unused bits: https://reviews.freebsd.org/D57505 because the fchroot(2) addition wiped out the beginning of the range and made it look like we only have one bit left there. Thanks, Kyle Evanshome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6d1d90b8-432a-4202-8d63-eb752913e315>