* [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
@ 2022-07-26 20:23 Jeff Layton
2022-07-26 20:27 ` Jeff Layton
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Layton @ 2022-07-26 20:23 UTC (permalink / raw)
To: viro
Cc: linux-fsdevel, linux-nfs, linux-kernel, Christian Brauner, Yongchen Yang
NFS server is exporting a sticky directory (mode 01777) with root
squashing enabled. Client has protect_regular enabled and then tries to
open a file as root in that directory. File is created (with ownership
set to nobody:nobody) but the open syscall returns an error.
The problem is may_create_in_sticky, which rejects the open even though
the file has already been created/opened. Only call may_create_in_sticky
if the file hasn't already been opened or created.
Cc: Christian Brauner <brauner@kernel.org>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
Reported-by: Yongchen Yang <yoyang@redhat.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/namei.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 1f28d3f463c3..7480b6dc8d27 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
return -EEXIST;
if (d_is_dir(nd->path.dentry))
return -EISDIR;
- error = may_create_in_sticky(mnt_userns, nd,
- d_backing_inode(nd->path.dentry));
- if (unlikely(error))
- return error;
+ if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
+ error = may_create_in_sticky(mnt_userns, nd,
+ d_backing_inode(nd->path.dentry));
+ if (unlikely(error)) {
+ printk("%s: f_mode=0x%x oflag=0x%x\n",
+ __func__, file->f_mode, open_flag);
+ return error;
+ }
+ }
}
if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
return -ENOTDIR;
--
2.37.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
2022-07-26 20:23 [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created Jeff Layton
@ 2022-07-26 20:27 ` Jeff Layton
2022-07-27 11:34 ` Christian Brauner
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Layton @ 2022-07-26 20:27 UTC (permalink / raw)
To: viro
Cc: linux-fsdevel, linux-nfs, linux-kernel, Christian Brauner, Yongchen Yang
On Tue, 2022-07-26 at 16:23 -0400, Jeff Layton wrote:
> NFS server is exporting a sticky directory (mode 01777) with root
> squashing enabled. Client has protect_regular enabled and then tries to
> open a file as root in that directory. File is created (with ownership
> set to nobody:nobody) but the open syscall returns an error.
>
> The problem is may_create_in_sticky, which rejects the open even though
> the file has already been created/opened. Only call may_create_in_sticky
> if the file hasn't already been opened or created.
>
> Cc: Christian Brauner <brauner@kernel.org>
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
> Reported-by: Yongchen Yang <yoyang@redhat.com>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/namei.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 1f28d3f463c3..7480b6dc8d27 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
> return -EEXIST;
> if (d_is_dir(nd->path.dentry))
> return -EISDIR;
> - error = may_create_in_sticky(mnt_userns, nd,
> - d_backing_inode(nd->path.dentry));
> - if (unlikely(error))
> - return error;
> + if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
> + error = may_create_in_sticky(mnt_userns, nd,
> + d_backing_inode(nd->path.dentry));
> + if (unlikely(error)) {
> + printk("%s: f_mode=0x%x oflag=0x%x\n",
> + __func__, file->f_mode, open_flag);
> + return error;
> + }
> + }
> }
> if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> return -ENOTDIR;
I'm pretty sure this patch is the wrong approach, actually, since it
doesn't fix the regular (non-atomic) open codepath. Any thoughts on what
the right fix might be?
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
2022-07-26 20:27 ` Jeff Layton
@ 2022-07-27 11:34 ` Christian Brauner
2022-07-27 11:48 ` Christian Brauner
2022-07-27 12:04 ` Jeff Layton
0 siblings, 2 replies; 8+ messages in thread
From: Christian Brauner @ 2022-07-27 11:34 UTC (permalink / raw)
To: Jeff Layton; +Cc: viro, linux-fsdevel, linux-nfs, linux-kernel, Yongchen Yang
On Tue, Jul 26, 2022 at 04:27:56PM -0400, Jeff Layton wrote:
> On Tue, 2022-07-26 at 16:23 -0400, Jeff Layton wrote:
> > NFS server is exporting a sticky directory (mode 01777) with root
> > squashing enabled. Client has protect_regular enabled and then tries to
> > open a file as root in that directory. File is created (with ownership
> > set to nobody:nobody) but the open syscall returns an error.
> >
> > The problem is may_create_in_sticky, which rejects the open even though
> > the file has already been created/opened. Only call may_create_in_sticky
> > if the file hasn't already been opened or created.
> >
> > Cc: Christian Brauner <brauner@kernel.org>
> > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
> > Reported-by: Yongchen Yang <yoyang@redhat.com>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/namei.c | 13 +++++++++----
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 1f28d3f463c3..7480b6dc8d27 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
> > return -EEXIST;
> > if (d_is_dir(nd->path.dentry))
> > return -EISDIR;
> > - error = may_create_in_sticky(mnt_userns, nd,
> > - d_backing_inode(nd->path.dentry));
> > - if (unlikely(error))
> > - return error;
> > + if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
> > + error = may_create_in_sticky(mnt_userns, nd,
> > + d_backing_inode(nd->path.dentry));
> > + if (unlikely(error)) {
> > + printk("%s: f_mode=0x%x oflag=0x%x\n",
> > + __func__, file->f_mode, open_flag);
> > + return error;
> > + }
> > + }
> > }
> > if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> > return -ENOTDIR;
>
> I'm pretty sure this patch is the wrong approach, actually, since it
> doesn't fix the regular (non-atomic) open codepath. Any thoughts on what
Hey Jeff,
I haven't quite understood why that won't work for the regular open
codepaths. I'm probably missing something obvious.
> the right fix might be?
When an actual creation has taken place - and not just a lookup - then
may_create_in_sticky() assumes that the owner of the inode matches
current_fsuid(). That'd would also be problematic on fat or in fact on
any fs where the actual inode->i_{g,u}id are based on e.g. uid/gid mount
options and not on current_fsuid(), I think?
So in order to improve this we would need to work around that assumption
in some way. Either by skipping may_create_in_sticky() if the file got
created or by adapting may_create_in_sticky().
I only wonder whether skipping may_create_in_sticky() altogether might
be a bit too lax. One possibility that came to my mind might be to relax
this assumption when the file has been created and the creator has
CAP_FOWNER.
So (not compile tested or in any way) sm like:
diff --git a/fs/namei.c b/fs/namei.c
index 1f28d3f463c3..239e9f423346 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1221,7 +1221,8 @@ int may_linkat(struct user_namespace *mnt_userns, struct path *link)
* Returns 0 if the open is allowed, -ve on error.
*/
static int may_create_in_sticky(struct user_namespace *mnt_userns,
- struct nameidata *nd, struct inode *const inode)
+ struct nameidata *nd, struct inode *const inode,
+ bool created)
{
umode_t dir_mode = nd->dir_mode;
kuid_t dir_uid = nd->dir_uid;
@@ -1230,7 +1231,9 @@ static int may_create_in_sticky(struct user_namespace *mnt_userns,
(!sysctl_protected_regular && S_ISREG(inode->i_mode)) ||
likely(!(dir_mode & S_ISVTX)) ||
uid_eq(i_uid_into_mnt(mnt_userns, inode), dir_uid) ||
- uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)))
+ uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)) ||
+ (created &&
+ capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FOWNER)))
return 0;
if (likely(dir_mode & 0002) ||
@@ -3496,7 +3499,8 @@ static int do_open(struct nameidata *nd,
if (d_is_dir(nd->path.dentry))
return -EISDIR;
error = may_create_in_sticky(mnt_userns, nd,
- d_backing_inode(nd->path.dentry));
+ d_backing_inode(nd->path.dentry),
+ (file->f_mode & FMODE_CREATED));
if (unlikely(error))
return error;
}
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
2022-07-27 11:34 ` Christian Brauner
@ 2022-07-27 11:48 ` Christian Brauner
2022-07-27 12:04 ` Jeff Layton
1 sibling, 0 replies; 8+ messages in thread
From: Christian Brauner @ 2022-07-27 11:48 UTC (permalink / raw)
To: Jeff Layton; +Cc: viro, linux-fsdevel, linux-nfs, linux-kernel, Yongchen Yang
On Wed, Jul 27, 2022 at 01:34:13PM +0200, Christian Brauner wrote:
> On Tue, Jul 26, 2022 at 04:27:56PM -0400, Jeff Layton wrote:
> > On Tue, 2022-07-26 at 16:23 -0400, Jeff Layton wrote:
> > > NFS server is exporting a sticky directory (mode 01777) with root
> > > squashing enabled. Client has protect_regular enabled and then tries to
> > > open a file as root in that directory. File is created (with ownership
> > > set to nobody:nobody) but the open syscall returns an error.
> > >
> > > The problem is may_create_in_sticky, which rejects the open even though
> > > the file has already been created/opened. Only call may_create_in_sticky
> > > if the file hasn't already been opened or created.
> > >
> > > Cc: Christian Brauner <brauner@kernel.org>
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
> > > Reported-by: Yongchen Yang <yoyang@redhat.com>
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > fs/namei.c | 13 +++++++++----
> > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index 1f28d3f463c3..7480b6dc8d27 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/namei.c
> > > @@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
> > > return -EEXIST;
> > > if (d_is_dir(nd->path.dentry))
> > > return -EISDIR;
> > > - error = may_create_in_sticky(mnt_userns, nd,
> > > - d_backing_inode(nd->path.dentry));
> > > - if (unlikely(error))
> > > - return error;
> > > + if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
> > > + error = may_create_in_sticky(mnt_userns, nd,
> > > + d_backing_inode(nd->path.dentry));
> > > + if (unlikely(error)) {
> > > + printk("%s: f_mode=0x%x oflag=0x%x\n",
> > > + __func__, file->f_mode, open_flag);
> > > + return error;
> > > + }
> > > + }
> > > }
> > > if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> > > return -ENOTDIR;
> >
> > I'm pretty sure this patch is the wrong approach, actually, since it
> > doesn't fix the regular (non-atomic) open codepath. Any thoughts on what
>
> Hey Jeff,
>
> I haven't quite understood why that won't work for the regular open
> codepaths. I'm probably missing something obvious.
>
> > the right fix might be?
>
> When an actual creation has taken place - and not just a lookup - then
> may_create_in_sticky() assumes that the owner of the inode matches
> current_fsuid(). That'd would also be problematic on fat or in fact on
> any fs where the actual inode->i_{g,u}id are based on e.g. uid/gid mount
> options and not on current_fsuid(), I think?
>
> So in order to improve this we would need to work around that assumption
> in some way. Either by skipping may_create_in_sticky() if the file got
> created or by adapting may_create_in_sticky().
>
> I only wonder whether skipping may_create_in_sticky() altogether might
> be a bit too lax. One possibility that came to my mind might be to relax
> this assumption when the file has been created and the creator has
> CAP_FOWNER.
>
> So (not compile tested or in any way) sm like:
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 1f28d3f463c3..239e9f423346 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1221,7 +1221,8 @@ int may_linkat(struct user_namespace *mnt_userns, struct path *link)
> * Returns 0 if the open is allowed, -ve on error.
> */
> static int may_create_in_sticky(struct user_namespace *mnt_userns,
> - struct nameidata *nd, struct inode *const inode)
> + struct nameidata *nd, struct inode *const inode,
> + bool created)
> {
> umode_t dir_mode = nd->dir_mode;
> kuid_t dir_uid = nd->dir_uid;
> @@ -1230,7 +1231,9 @@ static int may_create_in_sticky(struct user_namespace *mnt_userns,
> (!sysctl_protected_regular && S_ISREG(inode->i_mode)) ||
> likely(!(dir_mode & S_ISVTX)) ||
> uid_eq(i_uid_into_mnt(mnt_userns, inode), dir_uid) ||
> - uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)))
> + uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)) ||
> + (created &&
> + capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FOWNER)))
Sorry, this should be inode_owner_or_capable(mnt_userns, inode)
> return 0;
>
> if (likely(dir_mode & 0002) ||
> @@ -3496,7 +3499,8 @@ static int do_open(struct nameidata *nd,
> if (d_is_dir(nd->path.dentry))
> return -EISDIR;
> error = may_create_in_sticky(mnt_userns, nd,
> - d_backing_inode(nd->path.dentry));
> + d_backing_inode(nd->path.dentry),
> + (file->f_mode & FMODE_CREATED));
> if (unlikely(error))
> return error;
> }
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
2022-07-27 11:34 ` Christian Brauner
2022-07-27 11:48 ` Christian Brauner
@ 2022-07-27 12:04 ` Jeff Layton
2022-07-27 12:32 ` Christian Brauner
1 sibling, 1 reply; 8+ messages in thread
From: Jeff Layton @ 2022-07-27 12:04 UTC (permalink / raw)
To: Christian Brauner
Cc: viro, linux-fsdevel, linux-nfs, linux-kernel, Yongchen Yang
On Wed, 2022-07-27 at 13:34 +0200, Christian Brauner wrote:
> On Tue, Jul 26, 2022 at 04:27:56PM -0400, Jeff Layton wrote:
> > On Tue, 2022-07-26 at 16:23 -0400, Jeff Layton wrote:
> > > NFS server is exporting a sticky directory (mode 01777) with root
> > > squashing enabled. Client has protect_regular enabled and then tries to
> > > open a file as root in that directory. File is created (with ownership
> > > set to nobody:nobody) but the open syscall returns an error.
> > >
> > > The problem is may_create_in_sticky, which rejects the open even though
> > > the file has already been created/opened. Only call may_create_in_sticky
> > > if the file hasn't already been opened or created.
> > >
> > > Cc: Christian Brauner <brauner@kernel.org>
> > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
> > > Reported-by: Yongchen Yang <yoyang@redhat.com>
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > fs/namei.c | 13 +++++++++----
> > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index 1f28d3f463c3..7480b6dc8d27 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/namei.c
> > > @@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
> > > return -EEXIST;
> > > if (d_is_dir(nd->path.dentry))
> > > return -EISDIR;
> > > - error = may_create_in_sticky(mnt_userns, nd,
> > > - d_backing_inode(nd->path.dentry));
> > > - if (unlikely(error))
> > > - return error;
> > > + if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
> > > + error = may_create_in_sticky(mnt_userns, nd,
> > > + d_backing_inode(nd->path.dentry));
> > > + if (unlikely(error)) {
> > > + printk("%s: f_mode=0x%x oflag=0x%x\n",
> > > + __func__, file->f_mode, open_flag);
> > > + return error;
> > > + }
> > > + }
> > > }
> > > if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> > > return -ENOTDIR;
> >
> > I'm pretty sure this patch is the wrong approach, actually, since it
> > doesn't fix the regular (non-atomic) open codepath. Any thoughts on what
>
> Hey Jeff,
>
> I haven't quite understood why that won't work for the regular open
> codepaths. I'm probably missing something obvious.
>
In the normal open codepaths, FMODE_OPENED | FMODE_CREATED are still
clear. If we're not doing an atomic_open (i.e. the dentry doesn't exist
yet or is negative), then nothing really happens until you get to the
vfs_open call.
> > the right fix might be?
>
> When an actual creation has taken place - and not just a lookup - then
> may_create_in_sticky() assumes that the owner of the inode matches
> current_fsuid(). That'd would also be problematic on fat or in fact on
> any fs where the actual inode->i_{g,u}id are based on e.g. uid/gid mount
> options and not on current_fsuid(), I think?
>
> So in order to improve this we would need to work around that assumption
> in some way. Either by skipping may_create_in_sticky() if the file got
> created or by adapting may_create_in_sticky().
>
> I only wonder whether skipping may_create_in_sticky() altogether might
> be a bit too lax. One possibility that came to my mind might be to relax
> this assumption when the file has been created and the creator has
> CAP_FOWNER.
>
That may be the best option. I'll tinker around with that and see if I
can get it to work. Thanks for the suggestion.
> So (not compile tested or in any way) sm like:
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 1f28d3f463c3..239e9f423346 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1221,7 +1221,8 @@ int may_linkat(struct user_namespace *mnt_userns, struct path *link)
> * Returns 0 if the open is allowed, -ve on error.
> */
> static int may_create_in_sticky(struct user_namespace *mnt_userns,
> - struct nameidata *nd, struct inode *const inode)
> + struct nameidata *nd, struct inode *const inode,
> + bool created)
> {
> umode_t dir_mode = nd->dir_mode;
> kuid_t dir_uid = nd->dir_uid;
> @@ -1230,7 +1231,9 @@ static int may_create_in_sticky(struct user_namespace *mnt_userns,
> (!sysctl_protected_regular && S_ISREG(inode->i_mode)) ||
> likely(!(dir_mode & S_ISVTX)) ||
> uid_eq(i_uid_into_mnt(mnt_userns, inode), dir_uid) ||
> - uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)))
> + uid_eq(current_fsuid(), i_uid_into_mnt(mnt_userns, inode)) ||
> + (created &&
> + capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FOWNER)))
> return 0;
>
> if (likely(dir_mode & 0002) ||
> @@ -3496,7 +3499,8 @@ static int do_open(struct nameidata *nd,
> if (d_is_dir(nd->path.dentry))
> return -EISDIR;
> error = may_create_in_sticky(mnt_userns, nd,
> - d_backing_inode(nd->path.dentry));
> + d_backing_inode(nd->path.dentry),
> + (file->f_mode & FMODE_CREATED));
> if (unlikely(error))
> return error;
> }
I think that still won't fix it in the normal open codepath.
FMODE_CREATED won't be set, so this will just end up failing again.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
2022-07-27 12:04 ` Jeff Layton
@ 2022-07-27 12:32 ` Christian Brauner
2022-07-27 13:00 ` Jeff Layton
0 siblings, 1 reply; 8+ messages in thread
From: Christian Brauner @ 2022-07-27 12:32 UTC (permalink / raw)
To: Jeff Layton; +Cc: viro, linux-fsdevel, linux-nfs, linux-kernel, Yongchen Yang
On Wed, Jul 27, 2022 at 08:04:34AM -0400, Jeff Layton wrote:
> On Wed, 2022-07-27 at 13:34 +0200, Christian Brauner wrote:
> > On Tue, Jul 26, 2022 at 04:27:56PM -0400, Jeff Layton wrote:
> > > On Tue, 2022-07-26 at 16:23 -0400, Jeff Layton wrote:
> > > > NFS server is exporting a sticky directory (mode 01777) with root
> > > > squashing enabled. Client has protect_regular enabled and then tries to
> > > > open a file as root in that directory. File is created (with ownership
> > > > set to nobody:nobody) but the open syscall returns an error.
> > > >
> > > > The problem is may_create_in_sticky, which rejects the open even though
> > > > the file has already been created/opened. Only call may_create_in_sticky
> > > > if the file hasn't already been opened or created.
> > > >
> > > > Cc: Christian Brauner <brauner@kernel.org>
> > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
> > > > Reported-by: Yongchen Yang <yoyang@redhat.com>
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > ---
> > > > fs/namei.c | 13 +++++++++----
> > > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/fs/namei.c b/fs/namei.c
> > > > index 1f28d3f463c3..7480b6dc8d27 100644
> > > > --- a/fs/namei.c
> > > > +++ b/fs/namei.c
> > > > @@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
> > > > return -EEXIST;
> > > > if (d_is_dir(nd->path.dentry))
> > > > return -EISDIR;
> > > > - error = may_create_in_sticky(mnt_userns, nd,
> > > > - d_backing_inode(nd->path.dentry));
> > > > - if (unlikely(error))
> > > > - return error;
> > > > + if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
> > > > + error = may_create_in_sticky(mnt_userns, nd,
> > > > + d_backing_inode(nd->path.dentry));
> > > > + if (unlikely(error)) {
> > > > + printk("%s: f_mode=0x%x oflag=0x%x\n",
> > > > + __func__, file->f_mode, open_flag);
> > > > + return error;
> > > > + }
> > > > + }
> > > > }
> > > > if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> > > > return -ENOTDIR;
> > >
> > > I'm pretty sure this patch is the wrong approach, actually, since it
> > > doesn't fix the regular (non-atomic) open codepath. Any thoughts on what
> >
> > Hey Jeff,
> >
> > I haven't quite understood why that won't work for the regular open
> > codepaths. I'm probably missing something obvious.
> >
>
> In the normal open codepaths, FMODE_OPENED | FMODE_CREATED are still
> clear. If we're not doing an atomic_open (i.e. the dentry doesn't exist
> yet or is negative), then nothing really happens until you get to the
> vfs_open call.
Hm, so for atomic open with O_CREAT it's:
path_openat()
-> open_last_lookups()
-> lookup_open()
/*
* This is ->atomic_open() and FMODE_CREATED is set in the fs so
* for NFS it's done in:
* fs/nfs/dir.c: file->f_mode |= FMODE_CREATED;
*/
-> atomic_open()
and for regular O_CREAT open it's:
path_openat()
-> open_last_lookups()
-> lookup_open()
{
if (!dentry->d_inode && (open_flag & O_CREAT)) {
file->f_mode |= FMODE_CREATED;
}
and that should all get surfaced to:
path_openat()
-> do_open()
-> may_create_in_sticky()
?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
2022-07-27 12:32 ` Christian Brauner
@ 2022-07-27 13:00 ` Jeff Layton
2022-07-27 13:17 ` Christian Brauner
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Layton @ 2022-07-27 13:00 UTC (permalink / raw)
To: Christian Brauner
Cc: viro, linux-fsdevel, linux-nfs, linux-kernel, Yongchen Yang
On Wed, 2022-07-27 at 14:32 +0200, Christian Brauner wrote:
> On Wed, Jul 27, 2022 at 08:04:34AM -0400, Jeff Layton wrote:
> > On Wed, 2022-07-27 at 13:34 +0200, Christian Brauner wrote:
> > > On Tue, Jul 26, 2022 at 04:27:56PM -0400, Jeff Layton wrote:
> > > > On Tue, 2022-07-26 at 16:23 -0400, Jeff Layton wrote:
> > > > > NFS server is exporting a sticky directory (mode 01777) with root
> > > > > squashing enabled. Client has protect_regular enabled and then tries to
> > > > > open a file as root in that directory. File is created (with ownership
> > > > > set to nobody:nobody) but the open syscall returns an error.
> > > > >
> > > > > The problem is may_create_in_sticky, which rejects the open even though
> > > > > the file has already been created/opened. Only call may_create_in_sticky
> > > > > if the file hasn't already been opened or created.
> > > > >
> > > > > Cc: Christian Brauner <brauner@kernel.org>
> > > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
> > > > > Reported-by: Yongchen Yang <yoyang@redhat.com>
> > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > > ---
> > > > > fs/namei.c | 13 +++++++++----
> > > > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/fs/namei.c b/fs/namei.c
> > > > > index 1f28d3f463c3..7480b6dc8d27 100644
> > > > > --- a/fs/namei.c
> > > > > +++ b/fs/namei.c
> > > > > @@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
> > > > > return -EEXIST;
> > > > > if (d_is_dir(nd->path.dentry))
> > > > > return -EISDIR;
> > > > > - error = may_create_in_sticky(mnt_userns, nd,
> > > > > - d_backing_inode(nd->path.dentry));
> > > > > - if (unlikely(error))
> > > > > - return error;
> > > > > + if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
> > > > > + error = may_create_in_sticky(mnt_userns, nd,
> > > > > + d_backing_inode(nd->path.dentry));
> > > > > + if (unlikely(error)) {
> > > > > + printk("%s: f_mode=0x%x oflag=0x%x\n",
> > > > > + __func__, file->f_mode, open_flag);
> > > > > + return error;
> > > > > + }
> > > > > + }
> > > > > }
> > > > > if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> > > > > return -ENOTDIR;
> > > >
> > > > I'm pretty sure this patch is the wrong approach, actually, since it
> > > > doesn't fix the regular (non-atomic) open codepath. Any thoughts on what
> > >
> > > Hey Jeff,
> > >
> > > I haven't quite understood why that won't work for the regular open
> > > codepaths. I'm probably missing something obvious.
> > >
> >
> > In the normal open codepaths, FMODE_OPENED | FMODE_CREATED are still
> > clear. If we're not doing an atomic_open (i.e. the dentry doesn't exist
> > yet or is negative), then nothing really happens until you get to the
> > vfs_open call.
>
> Hm, so for atomic open with O_CREAT it's:
>
> path_openat()
> -> open_last_lookups()
> -> lookup_open()
> /*
> * This is ->atomic_open() and FMODE_CREATED is set in the fs so
> * for NFS it's done in:
> * fs/nfs/dir.c: file->f_mode |= FMODE_CREATED;
> */
> -> atomic_open()
>
> and for regular O_CREAT open it's:
>
> path_openat()
> -> open_last_lookups()
> -> lookup_open()
> {
> if (!dentry->d_inode && (open_flag & O_CREAT)) {
> file->f_mode |= FMODE_CREATED;
> }
>
>
> and that should all get surfaced to:
>
> path_openat()
> -> do_open()
> -> may_create_in_sticky()
>
> ?
Basically, yes, but we also need to deal with the case where the file
already exists. That's being denied currently too and I don't think it
should be.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created
2022-07-27 13:00 ` Jeff Layton
@ 2022-07-27 13:17 ` Christian Brauner
0 siblings, 0 replies; 8+ messages in thread
From: Christian Brauner @ 2022-07-27 13:17 UTC (permalink / raw)
To: Jeff Layton; +Cc: viro, linux-fsdevel, linux-nfs, linux-kernel, Yongchen Yang
On Wed, Jul 27, 2022 at 09:00:46AM -0400, Jeff Layton wrote:
> On Wed, 2022-07-27 at 14:32 +0200, Christian Brauner wrote:
> > On Wed, Jul 27, 2022 at 08:04:34AM -0400, Jeff Layton wrote:
> > > On Wed, 2022-07-27 at 13:34 +0200, Christian Brauner wrote:
> > > > On Tue, Jul 26, 2022 at 04:27:56PM -0400, Jeff Layton wrote:
> > > > > On Tue, 2022-07-26 at 16:23 -0400, Jeff Layton wrote:
> > > > > > NFS server is exporting a sticky directory (mode 01777) with root
> > > > > > squashing enabled. Client has protect_regular enabled and then tries to
> > > > > > open a file as root in that directory. File is created (with ownership
> > > > > > set to nobody:nobody) but the open syscall returns an error.
> > > > > >
> > > > > > The problem is may_create_in_sticky, which rejects the open even though
> > > > > > the file has already been created/opened. Only call may_create_in_sticky
> > > > > > if the file hasn't already been opened or created.
> > > > > >
> > > > > > Cc: Christian Brauner <brauner@kernel.org>
> > > > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1976829
> > > > > > Reported-by: Yongchen Yang <yoyang@redhat.com>
> > > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > > > ---
> > > > > > fs/namei.c | 13 +++++++++----
> > > > > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/fs/namei.c b/fs/namei.c
> > > > > > index 1f28d3f463c3..7480b6dc8d27 100644
> > > > > > --- a/fs/namei.c
> > > > > > +++ b/fs/namei.c
> > > > > > @@ -3495,10 +3495,15 @@ static int do_open(struct nameidata *nd,
> > > > > > return -EEXIST;
> > > > > > if (d_is_dir(nd->path.dentry))
> > > > > > return -EISDIR;
> > > > > > - error = may_create_in_sticky(mnt_userns, nd,
> > > > > > - d_backing_inode(nd->path.dentry));
> > > > > > - if (unlikely(error))
> > > > > > - return error;
> > > > > > + if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
> > > > > > + error = may_create_in_sticky(mnt_userns, nd,
> > > > > > + d_backing_inode(nd->path.dentry));
> > > > > > + if (unlikely(error)) {
> > > > > > + printk("%s: f_mode=0x%x oflag=0x%x\n",
> > > > > > + __func__, file->f_mode, open_flag);
> > > > > > + return error;
> > > > > > + }
> > > > > > + }
> > > > > > }
> > > > > > if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
> > > > > > return -ENOTDIR;
> > > > >
> > > > > I'm pretty sure this patch is the wrong approach, actually, since it
> > > > > doesn't fix the regular (non-atomic) open codepath. Any thoughts on what
> > > >
> > > > Hey Jeff,
> > > >
> > > > I haven't quite understood why that won't work for the regular open
> > > > codepaths. I'm probably missing something obvious.
> > > >
> > >
> > > In the normal open codepaths, FMODE_OPENED | FMODE_CREATED are still
> > > clear. If we're not doing an atomic_open (i.e. the dentry doesn't exist
> > > yet or is negative), then nothing really happens until you get to the
> > > vfs_open call.
> >
> > Hm, so for atomic open with O_CREAT it's:
> >
> > path_openat()
> > -> open_last_lookups()
> > -> lookup_open()
> > /*
> > * This is ->atomic_open() and FMODE_CREATED is set in the fs so
> > * for NFS it's done in:
> > * fs/nfs/dir.c: file->f_mode |= FMODE_CREATED;
> > */
> > -> atomic_open()
> >
> > and for regular O_CREAT open it's:
> >
> > path_openat()
> > -> open_last_lookups()
> > -> lookup_open()
> > {
> > if (!dentry->d_inode && (open_flag & O_CREAT)) {
> > file->f_mode |= FMODE_CREATED;
> > }
> >
> >
> > and that should all get surfaced to:
> >
> > path_openat()
> > -> do_open()
> > -> may_create_in_sticky()
> >
> > ?
>
> Basically, yes, but we also need to deal with the case where the file
> already exists. That's being denied currently too and I don't think it
> should be.
Yeah, that's the part I'm not sure I agree with (see other thread).
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-07-27 13:18 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-26 20:23 [RFC PATCH] vfs: don't check may_create_in_sticky if the file is already open/created Jeff Layton
2022-07-26 20:27 ` Jeff Layton
2022-07-27 11:34 ` Christian Brauner
2022-07-27 11:48 ` Christian Brauner
2022-07-27 12:04 ` Jeff Layton
2022-07-27 12:32 ` Christian Brauner
2022-07-27 13:00 ` Jeff Layton
2022-07-27 13:17 ` Christian Brauner
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).