From nobody Mon Jun 8 17:06:54 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gYz3j29Ynz6gPF5; Mon, 08 Jun 2026 17:06:57 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gYz3j1cGXz3Gq3; Mon, 08 Jun 2026 17:06:57 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1780938417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Inw+3OKQt1QWKBuYRUlf6ik5i/Syr/IbM7kgPs8rXAU=; b=xojkwBi4T+O/eAGH1SFXio02S42XAnLLyTCVsbWivZ8dEWDGLPmksleETSmsP45lVYlB+h ivBjW9b4JVi1YkDmgpqQJD8+MSWYRnd4T+SXqR/uNnwaF1ue2MWNDmQMzhtWH4YVKxiVmb tf7jpBA5Wyt1nY9oXzUuo39uF2GQ8H26KfOWqno0DNo7o3dcnYzrPY8+5wDEzlEMyRv2pQ 8Bw6Ea7sPgP8TxIIGE9qsS5izLDTld3iWu+UNrayEUuF7xDeGcQ2sjf/OxC7AJhlG2tBx1 iDnbDD7+Q7Sa3UxFzBYwCCvyW0h7m84yUt/BNn0GgDJz/zPnxaElbfwLT1WvvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1780938417; a=rsa-sha256; cv=none; b=Bq7bmt0thmAgBHS5dPLaHKT6IUHvQfILvpKc5hw4nXvCYiBoqnwSdOPMscZfkdDe6lHp/b ZVpmZUexeTun8TtAdyyfm+9xp5WA8YrZIebhnQQlCXKnnJYRBbLNATK4zkU0x/lxGMTC7F QkkRX/xKlM127DUirXggcXFwlzjRtX8GKnY0HPWobkZgN+nezjI/EIzNbWB0ALdtIdiaGQ eum0pzzNB4LtNKda+MC4B+zbfcQU20q+CW22g9AsBuGRJLY8npuYOKCg8dabFMq1Zm2rLW PDePhiASLcDDNWrQQgBKhkfmrWoDHNBDHLsRl5SC3hSkActiQhmAbZJJovF9Uw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1780938417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Inw+3OKQt1QWKBuYRUlf6ik5i/Syr/IbM7kgPs8rXAU=; b=k0Bn8PQsgRgO0wFGXeZ+7WELxq6u8KTb9haieHvnsLIJccWvAfjfshQyEMFvXOGT51nv+C EknWnel6M+i746masnJsCqm0twPGb14+jwfc+wBqGvEHd2TB4lOB99NLNbpvWkpJZX8TJz 7303qthe13sV2aqB9D34VwN5iW7yxEd9oNbrDEPoVlRcARurTM4mWYN/wp6JKVgDAu+z84 LijOIsNeEw20AwOBnbTfWmtBm+xcUiEWKurM1xAms9ztH3LTyjHL00FHwNuAQV5LahgiMv CF7AeEncBgstAAXSYAmhYXw0C2+8jDve6/StfvV+H5yNc50Y4Nd9aJVNWiMWPA== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4gYz3h3z9xz16xh; Mon, 08 Jun 2026 17:06:56 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <6d1d90b8-432a-4202-8d63-eb752913e315@FreeBSD.org> Date: Mon, 8 Jun 2026 12:06:54 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: rights(4) split? CAP_WRITE -> CAP_WRITE_DATA + CAP_WRITE_CTRL To: Mark Johnston Cc: Mariusz Zaborski , "freebsd-hackers@FreeBSD.org" , freebsd-arch@freebsd.org, pjd@freebsd.org References: <7f5f2137-bd4d-4e27-8049-cf585849103e@FreeBSD.org> <4feb230b-635e-4eca-8d9e-f89df2ad1377@FreeBSD.org> Content-Language: en-US From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Evans