From nobody Sun Dec 01 00:25:30 2024 X-Original-To: dev-commits-src-all@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 4Y1748141hz5fvCG for ; Sun, 01 Dec 2024 00:25:44 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y17470W2Zz4vg7 for ; Sun, 1 Dec 2024 00:25:43 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sippysoft.com header.s=google header.b=QVx6Dt0B; spf=pass (mx1.freebsd.org: domain of sobomax@sippysoft.com designates 2607:f8b0:4864:20::102a as permitted sender) smtp.mailfrom=sobomax@sippysoft.com; dmarc=pass (policy=none) header.from=sippysoft.com Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2eeb2e749c5so9961a91.0 for ; Sat, 30 Nov 2024 16:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft.com; s=google; t=1733012742; x=1733617542; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ck87qa/3RPzXbuKJ0pcvzmgPV9Wc9R3RkZVwoakG/Pw=; b=QVx6Dt0B0eK7qfmf4gyt9cb/rhwOPheLQ6nxRjVa2tdYnyRIVNgktQd0l/Vw6ZrKG8 oydniymCAWYjbAtcpRk/lMZvvywG8WqTHKje+UtT6/8IVEHU4k89aaSlRnqQwhRO78uZ YKStXDfgybhk2qEam9d4wBEF+NweBc6tsjt6s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733012742; x=1733617542; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ck87qa/3RPzXbuKJ0pcvzmgPV9Wc9R3RkZVwoakG/Pw=; b=gEyMu2pzMtUCyWUwT849ZkrugPDeLBqu7eV9KjrmrQtA5rkSNsZ0A79edVyhEeZw1h IC6aM4dPltZCfHy81+ynFweoknDIboTursOG4zdBFXzCFL09QVwBRV2iBLZKv1UIels2 7CQbNAomDzQ8/aHHy9mwFQ5FXuMJZwBFHu+IsvGKJ6hMf3HHgqul/bst+21Y95Al2yix h3OCORWpDS8AntjfFIGLgDAnVhDeffoTUK7lSHIyXxhhU0CNVIE6kr8fj4/EemNuOYwP hOg21PDH6+bqj1LCZZ6sN5VsNkIaRYaooPYrKNKNV/flIM2XXlzwzembKQC3DlYBfJsJ WQsw== X-Forwarded-Encrypted: i=1; AJvYcCVNLGs3USr+uNazZ4vqiwpWQ883EBrZwsIiWCe3CRt0i0plIGoywb1maZzUs6DBJC1D7VcRjeqQdclnH5fe2FNg1FbK@freebsd.org X-Gm-Message-State: AOJu0Yz7jRCs/WR/DnwzuBUvBUB9rL60gnnYsp6jTyRjNhuXSMCeDdP7 55PZ7EHThFW5G9e50AqZaQg5lQrT/BOOF7/V/eHmJOcsweroynk6Uhp2gR0LtNUAM6hMqUbDYFZ Q9+0L+CT4JrAa7AkS2a4uaMqY8+6cArNOPP3nfw== X-Gm-Gg: ASbGnctwkQ3keMUdD0wPkRv28Yo11bCi9QRvGMr7abDUF1KrSsGsKk907ZqvRPqxCtm o7y/XZEkeI3yzNhoxsg4xdB8UartZDx5mM9AaoGFQSCFtuhg28tiMEge/63MPBQ1quw== X-Google-Smtp-Source: AGHT+IGaXfP4Z+XU2Taci3qYcjjP1TRX1uCZllHhhbJQqMWgMHgzW8QYNYeWy++YtbRoMTh45gM7RcuAKVEoPTIYQFE= X-Received: by 2002:a17:90b:4b87:b0:2ea:6551:da5d with SMTP id 98e67ed59e1d1-2ee08eb2b6emr20673708a91.13.1733012741653; Sat, 30 Nov 2024 16:25:41 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202411291222.4ATCMG8Y068265@gitrepo.freebsd.org> In-Reply-To: From: Maxim Sobolev Date: Sat, 30 Nov 2024 16:25:30 -0800 Message-ID: Subject: Re: git: b165e9e3ea4e - main - Add fchroot(2) To: Konstantin Belousov Cc: Edward Tomasz Napierala , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000dba1f606282a7800" X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[sippysoft.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[sippysoft.com:s=google]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[sobomax]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102a:from]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-all@freebsd.org]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; DKIM_TRACE(0.00)[sippysoft.com:+] X-Rspamd-Queue-Id: 4Y17470W2Zz4vg7 X-Spamd-Bar: --- --000000000000dba1f606282a7800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is crazy and should be stopped at some point. I usually have a rule of thumb, is that if I have to duplicate same API third time to accomodate slightly different but largely the same usage scenario then it's time to unify and generalize. By that rule stat() and fstat() are ok, but at the time we felt the need to add statat()/fstatat() we should have stopped and instead do a single xstat() that would encapsulate all 4 including original stat() and fstat() and declare those compat_stat() and compat_fstat(). Plus make internal structure future-proof by giving it a version number. Of course none of this actually happened, so the same story repeats over and over for dozen of other syscals. To make things worse each of the time basic ABI changes (i.e. struct stat in this example, so we just copy all 4, ending up with 8 syscals to care for where one would do. All this contributed greatly to the fact that we are now pushing into 600 of syscals= . But why does it matter, I hear you say? Aren't syscals semi-private, between our kernel and our libc. Well it's actually not so. There are very popular tools and frameworks out there bypassing libc and calling into kernel directly (golang for example, rust may be too). I suspect for that reason we still have large chunk of freebsd11_xxx syscals shipped as first class citizens in 14.x releases. Golang is particularly funny, since in the core it would call latest kevent, but if you are using kevent from their os package, you'd get compat11_kevent. The chroot() would be particularly easy to make an exemplary in this, by making xchroot(2), renaming chroot(2) into compat15_chroot(2) and making both chroot(3) and fchroot(3) wrappers for xchroot(2). I am even willing to do PoC if someone is willing to consider it. -Max On Fri, Nov 29, 2024, 7:25=E2=80=AFAM Konstantin Belousov wrote: > On Fri, Nov 29, 2024 at 12:22:16PM +0000, Edward Tomasz Napierala wrote: > > The branch main has been updated by trasz: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=3Db165e9e3ea4e327fc421d81c2a89242= bd8720780 > > > > commit b165e9e3ea4e327fc421d81c2a89242bd8720780 > > Author: Edward Tomasz Napierala > > AuthorDate: 2024-11-29 07:46:07 +0000 > > Commit: Edward Tomasz Napierala > > CommitDate: 2024-11-29 12:10:02 +0000 > > > > Add fchroot(2) > > > > 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 shoul= d > > be useful in other contexts too. > > I wonder if it should be fchrootat(fd, path, flags) with the support for > AT_EMPTY_PATH instead. Then fchroot() becomes the libc wrapper. > > I can see arguments both pro and contra. Main argument against is that > the immediate semantic is easily emulated by openat() + fchroot(). But > the freedom of adding the fchroot-specific flags might be worth > considering. > > --000000000000dba1f606282a7800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is crazy and should be stopped at some point. I usua= lly have a rule of thumb, is that if I have to duplicate same API third tim= e to accomodate slightly different but largely the same usage scenario then= it's time to unify and generalize. By that rule stat() and fstat() are= ok, but at the time we felt the need to add statat()/fstatat() we should h= ave stopped and instead do a single xstat() that would encapsulate all 4 in= cluding original stat() and fstat() and declare those compat_stat() and com= pat_fstat(). Plus make internal structure future-proof by giving it a versi= on number. Of course none of this actually happened, so the same story repe= ats over and over for dozen of other syscals. To make things worse each of = the time basic ABI changes (i.e. struct stat in this example, so we just co= py all 4, ending up with 8 syscals to care for where one would do. All this= contributed greatly to the fact that we are now pushing into 600 of syscal= s.

But why does it matter, I h= ear you say? Aren't syscals semi-private, between our kernel and our li= bc. Well it's actually not so. There are very popular tools and framewo= rks out there bypassing libc and calling into kernel directly (golang for e= xample, rust may be too). I suspect for that reason we still have large chu= nk of freebsd11_xxx syscals shipped as first class citizens in 14.x release= s. Golang is particularly funny, since in the core it would call latest kev= ent, but if you are using kevent from their os package, you'd get compa= t11_kevent.

The chroot()= would be particularly easy to make an exemplary in this, by making xchroot= (2), renaming chroot(2) into compat15_chroot(2) and making both chroot(3) a= nd fchroot(3) wrappers for xchroot(2). I am even willing to do PoC if someo= ne is willing to consider it.

-Max


On Fri, Nov 29, 2024, 7:25=E2=80=AFAM Konstantin= Belousov <kostikbel@gmail.com> wrote:
On Fri, Nov 29, 2024 a= t 12:22:16PM +0000, Edward Tomasz Napierala wrote:
> The branch main has been updated by trasz:
>
> URL: https://cgit.FreeBSD.org/src/commit/?id=3Db165e9e3ea4e327fc421d81c2a8924= 2bd8720780
>
> commit b165e9e3ea4e327fc421d81c2a89242bd8720780
> Author:=C2=A0 =C2=A0 =C2=A0Edward Tomasz Napierala <trasz@FreeBSD.o= rg>
> AuthorDate: 2024-11-29 07:46:07 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Edward Tomasz Napierala <trasz@FreeBSD.o= rg>
> CommitDate: 2024-11-29 12:10:02 +0000
>
>=C2=A0 =C2=A0 =C2=A0Add fchroot(2)
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0This is similar to chroot(2), but takes a file desc= riptor instead
>=C2=A0 =C2=A0 =C2=A0of path.=C2=A0 Same syscall exists in NetBSD and So= laris.=C2=A0 It is part of a larger
>=C2=A0 =C2=A0 =C2=A0patch to make absolute pathnames usable in Capsicum= mode, but should
>=C2=A0 =C2=A0 =C2=A0be useful in other contexts too.

I wonder if it should be fchrootat(fd, path, flags) with the support for AT_EMPTY_PATH instead.=C2=A0 Then fchroot() becomes the libc wrapper.

I can see arguments both pro and contra.=C2=A0 Main argument against is tha= t
the immediate semantic is easily emulated by openat() + fchroot().=C2=A0 Bu= t
the freedom of adding the fchroot-specific flags might be worth considering= .

--000000000000dba1f606282a7800--