From: Christoph Hellwig <hch@lst.de>
To: Christian Brauner <brauner@kernel.org>
Cc: "Mickaël Salaün" <mic@digikod.net>,
"Xiu Jianfeng" <xiujianfeng@huawei.com>,
gregkh@linuxfoundation.org, rafael@kernel.org,
viro@zeniv.linux.org.uk, dhowells@redhat.com, code@tyhicks.com,
hirofumi@mail.parknet.co.jp, linkinjeon@kernel.org,
sfrench@samba.org, senozhatsky@chromium.org, tom@talpey.com,
chuck.lever@oracle.com, jlayton@kernel.org, miklos@szeredi.hu,
paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
stephen.smalley.work@gmail.com, eparis@parisplace.org,
casey@schaufler-ca.com, dchinner@redhat.com,
john.johansen@canonical.com, mcgrof@kernel.org,
mortonm@chromium.org, fred@cloudflare.com, mpe@ellerman.id.au,
nathanl@linux.ibm.com, gnoack3000@gmail.com,
roberto.sassu@huawei.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com,
ecryptfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
wangweiyang2@huawei.com, "Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH -next 0/2] lsm: Change inode_setattr() to take struct
Date: Tue, 30 May 2023 16:28:26 +0200 [thread overview]
Message-ID: <20230530142826.GA9376@lst.de> (raw)
In-Reply-To: <20230530-mietfrei-zynisch-8b63a8566f66@brauner>
On Tue, May 30, 2023 at 03:58:35PM +0200, Christian Brauner wrote:
> The main concern which was expressed on other patchsets before is that
> modifying inode operations to take struct path is not the way to go.
> Passing struct path into individual filesystems is a clear layering
> violation for most inode operations, sometimes downright not feasible,
> and in general exposing struct vfsmount to filesystems is a hard no. At
> least as far as I'm concerned.
Agreed. Passing struct path into random places is not how the VFS works.
> So the best way to achieve the landlock goal might be to add new hooks
What is "the landlock goal", and why does it matter?
> or not. And we keep adding new LSMs without deprecating older ones (A
> problem we also face in the fs layer.) and then they sit around but
> still need to be taken into account when doing changes.
Yes, I'm really worried about th amount of LSMs we have, and the weird
things they do.
next prev parent reply other threads:[~2023-05-30 14:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 8:11 [PATCH -next 0/2] lsm: Change inode_setattr() to take struct Xiu Jianfeng
2023-05-05 8:11 ` [PATCH -next 1/2] fs: Change notify_change() to take struct path argument Xiu Jianfeng
2023-05-05 17:22 ` [PATCH -next 1/2] " Chuck Lever III
2023-05-05 8:12 ` [PATCH -next 2/2] lsm: Change inode_setattr hook " Xiu Jianfeng
2023-05-10 0:58 ` [PATCH -next 0/2] lsm: Change inode_setattr() to take struct xiujianfeng
2023-05-15 15:12 ` Christian Brauner
2023-05-26 16:33 ` Mickaël Salaün
2023-05-30 13:58 ` Christian Brauner
2023-05-30 14:28 ` Christoph Hellwig [this message]
2023-05-30 14:55 ` Casey Schaufler
2023-05-30 16:01 ` Christian Brauner
2023-05-30 22:15 ` Casey Schaufler
2023-05-31 8:36 ` Christian Brauner
2023-05-31 16:44 ` Casey Schaufler
2023-05-31 13:22 ` Christoph Hellwig
2023-05-31 14:17 ` Casey Schaufler
2023-05-31 15:22 ` Mickaël Salaün
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=20230530142826.GA9376@lst.de \
--to=hch@lst.de \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=chuck.lever@oracle.com \
--cc=code@tyhicks.com \
--cc=dchinner@redhat.com \
--cc=dhowells@redhat.com \
--cc=ecryptfs@vger.kernel.org \
--cc=eparis@parisplace.org \
--cc=fred@cloudflare.com \
--cc=gnoack3000@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jlayton@kernel.org \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cachefs@redhat.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mic@digikod.net \
--cc=miklos@szeredi.hu \
--cc=mortonm@chromium.org \
--cc=mpe@ellerman.id.au \
--cc=nathanl@linux.ibm.com \
--cc=paul@paul-moore.com \
--cc=rafael@kernel.org \
--cc=roberto.sassu@huawei.com \
--cc=selinux@vger.kernel.org \
--cc=senozhatsky@chromium.org \
--cc=serge@hallyn.com \
--cc=sfrench@samba.org \
--cc=stephen.smalley.work@gmail.com \
--cc=tom@talpey.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wangweiyang2@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.