From: "Günther Noack" <gnoack3000@gmail.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>,
linux-security-module@vger.kernel.org,
Paul Moore <paul@paul-moore.com>,
Konstantin Meskhidze <konstantin.meskhidze@huawei.com>,
Xiu Jianfeng <xiujianfeng@huawei.com>
Subject: Re: [PATCH v2] landlock: Clarify documentation for the LANDLOCK_ACCESS_FS_REFER right
Date: Thu, 16 Feb 2023 20:48:30 +0100 [thread overview]
Message-ID: <Y+6Ijsa7bXgf/meQ@galopp> (raw)
In-Reply-To: <a66bb3f7-9d8d-f2da-9b92-be489780c67b@digikod.net>
Hello!
On Thu, Feb 16, 2023 at 07:42:51PM +0100, Mickaël Salaün wrote:
> On 15/02/2023 21:34, Günther Noack wrote:
> > Sorry, correction (+ABI, s/to/for/):
> >
> > This access right is available since the second version of the
> > Landlock ABI. This is also the only access right which is
> > implicitly handled by any ruleset, even if the right is not
> > specified at the time of creating the ruleset. So, by default,
> > Landlock will deny linking and reparenting files between different
> > directories, and only grant this right when it is explicitly
>
> and will only grant…?
Good point, done.
> > > Both valid points. How about the following phrasing which is
> > > formulated a bit closer to the actual goal (not creating a loophole
> > > through which you can gain more access rights for a file):
> > >
> > > * The reparented file may not attain more access rights in the
>
> s/may not/cannot/ ?
I think "may not" is used when it's about permissions, whereas "can
not" is about ability. "may not" seems more appropriate here, because
the process is still free to attempt it, and we are explaining the
consequences below.
> s/attain/gain/ ?
Yes, thanks -- apparently, "attain" is more used for goals whereas
"gain" more for resources, so "gain" seems more correct here.
>
> > > destination directory than it previously had in the source
> > > directory. If this is attempted, the operation results in an
> > > ``EXDEV`` error.
>
> Better too!
>
> This is becoming a bit difficult to follow, you can send a new patch with
> Alex in Cc. :)
Thanks for the feedback, I will send a revised patch.
–-Günther
prev parent reply other threads:[~2023-02-16 19:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 21:01 [PATCH v2] landlock: Clarify documentation for the LANDLOCK_ACCESS_FS_REFER right Günther Noack
2023-02-14 12:04 ` Mickaël Salaün
2023-02-15 18:33 ` Günther Noack
2023-02-15 20:34 ` Günther Noack
2023-02-16 18:42 ` Mickaël Salaün
2023-02-16 19:48 ` Günther Noack [this message]
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=Y+6Ijsa7bXgf/meQ@galopp \
--to=gnoack3000@gmail.com \
--cc=alx.manpages@gmail.com \
--cc=konstantin.meskhidze@huawei.com \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=xiujianfeng@huawei.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