From: "Mickaël Salaün" <mic@digikod.net>
To: "Günther Noack" <gnoack3000@gmail.com>,
"Alejandro Colomar" <alx.manpages@gmail.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
linux-man@vger.kernel.org, landlock@lists.linux.dev
Subject: Re: [PATCH v3 1/2] landlock.7: Document Landlock ABI v2 (file reparenting; Linux 5.19)
Date: Tue, 7 Mar 2023 23:16:47 +0100 [thread overview]
Message-ID: <8a18c793-8d77-5781-8856-098bef2b349e@digikod.net> (raw)
In-Reply-To: <20230305.d639b17946bd@gnoack.org>
Thanks Günther. I agree with this approach. Let's start with a
common-enough example, and then point to exceptions. Targeting common
(and simple) utilities at first sounds reasonable.
On 05/03/2023 11:24, Günther Noack wrote:
> +landlock mailing list (feeback welcome)
>
> Hello!
>
> On Sat, Mar 04, 2023 at 06:16:06PM +0100, Günther Noack wrote:
>> * Add LANDLOCK_ACCESS_FS_REFER to the code example.
>
> To follow up on the discussion on the man page update v1 [1] -- let me
> make a constructive proposal for a simpler code example for "best
> effort" fallback in the man page.
>
> I feel that implementing the full generic "best effort" fallback logic
> would complicate the example too much:
>
> (a) examples that try to demonstrate too many things at once
> tend to become confusing to the reader
> (b) there are readers to whom the full example might not matter:
> - readers who know what kernel their software runs on
> - readers in the future or on cutting-edge distributions
> who can assume that their kernel is likely to be fresh enough
>
> The main complication with the "best effort" logic is really just that
> the "refer" right requires a different fallback logic, and this is
> easy to overlook (has happened in multiple instances already).
>
> I believe that many potential Landlock users, especially smaller
> tools, probably do not need to reparent files ("refer").
>
> We can group the existing Landlock use cases like this:
>
> Case 1: Callers who know they *do not* need to reparent files
> can skip the "refer" complications.
>
> Case 2: Callers who know they *do* need to reparent files
> need to fall back to no-op if the kernel only suppports ABI v1,
> as reparenting files is always forbidden with ABI v1.
>
> Case 3: Callers who *sometimes do and sometimes don't* reparent files
> are the only ones where it's harder to implement.
>
> I've put the required for code cases 1, 2, and 3 on my weblog at [2]
> (skip to the "Implementation" section).
>
> The complicated case 3 is what we need in the Go and Rust helper
> libraries for Landlock, but it should hopefully not be needed for
> most Landlock users who use it directly from C.
>
>
> **This is how I think we should describe it in the man page**:
>
> * Define the backwards compatibility table.
> * Implement fallback logic for programs
> which do *not* need to reparent files.
> * Call it out prominently that the fallback code is different
> if the program needs file reparenting, and explain that separately,
> in the man page or elsewhere.
>
> I believe this should cover the use cases for a large chunk of simple
> Unix tools, and I would like to encourage the use of Landlock in
> these. Readers should not have to adapt the example code to work in
> their program.
>
> Let me know what you think!
> –Günther
>
> [1] https://lore.kernel.org/linux-man/Y%2FcvfmEM1XEL%2FTPz@galopp/
> [2] https://blog.gnoack.org/post/landlock-best-effort/
next prev parent reply other threads:[~2023-03-07 22:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230304171607.8301-1-gnoack3000@gmail.com>
2023-03-05 10:24 ` [PATCH v3 1/2] landlock.7: Document Landlock ABI v2 (file reparenting; Linux 5.19) Günther Noack
2023-03-07 22:16 ` Mickaël Salaün [this message]
2023-03-10 0:31 ` Alejandro Colomar
2023-03-10 21:31 ` Günther Noack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a18c793-8d77-5781-8856-098bef2b349e@digikod.net \
--to=mic@digikod.net \
--cc=alx.manpages@gmail.com \
--cc=gnoack3000@gmail.com \
--cc=landlock@lists.linux.dev \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).