landlock.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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/

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