linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luís Henriques" <lhenriques@suse.de>
To: Xiubo Li <xiubli@redhat.com>
Cc: Max Kellermann <max.kellermann@ionos.com>,
	idryomov@gmail.com, jlayton@kernel.org,
	ceph-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs/ceph/super: add mount options "snapdir{mode,uid,gid}"
Date: Tue, 11 Oct 2022 10:28:48 +0100	[thread overview]
Message-ID: <Y0U3UAjugtpOlJqn@suse.de> (raw)
In-Reply-To: <88f8941f-82bf-5152-b49a-56cb2e465abb@redhat.com>

On Sun, Oct 09, 2022 at 02:23:22PM +0800, Xiubo Li wrote:
> Hi Max,
> 
> Sorry for late and just back from a long vocation.
> 
> On 27/09/2022 20:08, Max Kellermann wrote:
> > By default, the ".snap" directory inherits the parent's permissions
> > and ownership, which allows all users to create new cephfs snapshots
> > in arbitrary directories they have write access on.
> > 
> > In some environments, giving everybody this capability is not
> > desirable, but there is currently no way to disallow only some users
> > to create snapshots.  It is only possible to revoke the permission to
> > the whole client (i.e. all users on the computer which mounts the
> > cephfs).
> > 
> > This patch allows overriding the permissions and ownership of all
> > virtual ".snap" directories in a cephfs mount, which allows
> > restricting (read and write) access to snapshots.
> > 
> > For example, the mount options:
> > 
> >   snapdirmode=0751,snapdiruid=0,snapdirgid=4
> > 
> > ... allows only user "root" to create or delete snapshots, and group
> > "adm" (gid=4) is allowed to get a list of snapshots.  All others are
> > allowed to read the contents of existing snapshots (if they know the
> > name).
> 
> I don't think this is a good place to implement this in client side. Should
> this be a feature in cephx.
> 
> With this for the same directories in different mounts will behave
> differently. Isn't that odd ?

I'm not really sure where (or how) exactly this feature should be
implemented, but I agree with Xiubo that this approach doesn't look
correct.  This would be yet another hack that can be easily circumvented
on the client side.  If this feature is really required, the restriction
should be imposed on the MDS side.

(However, IMHO the feature looks odd from the beginning: a user that owns
a directory and has 'rw' access to it but can't run a simple 'mkdir' is
probably breaking standards compliance even more.)

Cheers,
--
Luís

> 
> -- Xiubo
> 
> > Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
> > ---
> >   fs/ceph/inode.c |  7 ++++---
> >   fs/ceph/super.c | 33 +++++++++++++++++++++++++++++++++
> >   fs/ceph/super.h |  4 ++++
> >   3 files changed, 41 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> > index 56c53ab3618e..0e9388af2821 100644
> > --- a/fs/ceph/inode.c
> > +++ b/fs/ceph/inode.c
> > @@ -80,6 +80,7 @@ struct inode *ceph_get_snapdir(struct inode *parent)
> >   	};
> >   	struct inode *inode = ceph_get_inode(parent->i_sb, vino);
> >   	struct ceph_inode_info *ci = ceph_inode(inode);
> > +	struct ceph_mount_options *const fsopt = ceph_inode_to_client(parent)->mount_options;
> >   	if (IS_ERR(inode))
> >   		return inode;
> > @@ -96,9 +97,9 @@ struct inode *ceph_get_snapdir(struct inode *parent)
> >   		goto err;
> >   	}
> > -	inode->i_mode = parent->i_mode;
> > -	inode->i_uid = parent->i_uid;
> > -	inode->i_gid = parent->i_gid;
> > +	inode->i_mode = fsopt->snapdir_mode == (umode_t)-1 ? parent->i_mode : fsopt->snapdir_mode;
> > +	inode->i_uid = uid_eq(fsopt->snapdir_uid, INVALID_UID) ? parent->i_uid : fsopt->snapdir_uid;
> > +	inode->i_gid = gid_eq(fsopt->snapdir_gid, INVALID_GID) ? parent->i_gid : fsopt->snapdir_gid;
> >   	inode->i_mtime = parent->i_mtime;
> >   	inode->i_ctime = parent->i_ctime;
> >   	inode->i_atime = parent->i_atime;
> > diff --git a/fs/ceph/super.c b/fs/ceph/super.c
> > index 40140805bdcf..5e5713946f7b 100644
> > --- a/fs/ceph/super.c
> > +++ b/fs/ceph/super.c
> > @@ -143,6 +143,9 @@ enum {
> >   	Opt_readdir_max_entries,
> >   	Opt_readdir_max_bytes,
> >   	Opt_congestion_kb,
> > +	Opt_snapdirmode,
> > +	Opt_snapdiruid,
> > +	Opt_snapdirgid,
> >   	/* int args above */
> >   	Opt_snapdirname,
> >   	Opt_mds_namespace,
> > @@ -200,6 +203,9 @@ static const struct fs_parameter_spec ceph_mount_parameters[] = {
> >   	fsparam_flag_no ("require_active_mds",		Opt_require_active_mds),
> >   	fsparam_u32	("rsize",			Opt_rsize),
> >   	fsparam_string	("snapdirname",			Opt_snapdirname),
> > +	fsparam_u32oct	("snapdirmode",			Opt_snapdirmode),
> > +	fsparam_u32	("snapdiruid",			Opt_snapdiruid),
> > +	fsparam_u32	("snapdirgid",			Opt_snapdirgid),
> >   	fsparam_string	("source",			Opt_source),
> >   	fsparam_string	("mon_addr",			Opt_mon_addr),
> >   	fsparam_u32	("wsize",			Opt_wsize),
> > @@ -414,6 +420,22 @@ static int ceph_parse_mount_param(struct fs_context *fc,
> >   		fsopt->snapdir_name = param->string;
> >   		param->string = NULL;
> >   		break;
> > +	case Opt_snapdirmode:
> > +		fsopt->snapdir_mode = result.uint_32;
> > +		if (fsopt->snapdir_mode & ~0777)
> > +			return invalfc(fc, "Invalid snapdirmode");
> > +		fsopt->snapdir_mode |= S_IFDIR;
> > +		break;
> > +	case Opt_snapdiruid:
> > +		fsopt->snapdir_uid = make_kuid(current_user_ns(), result.uint_32);
> > +		if (!uid_valid(fsopt->snapdir_uid))
> > +			return invalfc(fc, "Invalid snapdiruid");
> > +		break;
> > +	case Opt_snapdirgid:
> > +		fsopt->snapdir_gid = make_kgid(current_user_ns(), result.uint_32);
> > +		if (!gid_valid(fsopt->snapdir_gid))
> > +			return invalfc(fc, "Invalid snapdirgid");
> > +		break;
> >   	case Opt_mds_namespace:
> >   		if (!namespace_equals(fsopt, param->string, strlen(param->string)))
> >   			return invalfc(fc, "Mismatching mds_namespace");
> > @@ -734,6 +756,14 @@ static int ceph_show_options(struct seq_file *m, struct dentry *root)
> >   		seq_printf(m, ",readdir_max_bytes=%u", fsopt->max_readdir_bytes);
> >   	if (strcmp(fsopt->snapdir_name, CEPH_SNAPDIRNAME_DEFAULT))
> >   		seq_show_option(m, "snapdirname", fsopt->snapdir_name);
> > +	if (fsopt->snapdir_mode != (umode_t)-1)
> > +		seq_printf(m, ",snapdirmode=%o", fsopt->snapdir_mode);
> > +	if (!uid_eq(fsopt->snapdir_uid, INVALID_UID))
> > +		seq_printf(m, ",snapdiruid=%o",
> > +			   from_kuid_munged(&init_user_ns, fsopt->snapdir_uid));
> > +	if (!gid_eq(fsopt->snapdir_gid, INVALID_GID))
> > +		seq_printf(m, ",snapdirgid=%o",
> > +			   from_kgid_munged(&init_user_ns, fsopt->snapdir_gid));
> >   	return 0;
> >   }
> > @@ -1335,6 +1365,9 @@ static int ceph_init_fs_context(struct fs_context *fc)
> >   	fsopt->wsize = CEPH_MAX_WRITE_SIZE;
> >   	fsopt->rsize = CEPH_MAX_READ_SIZE;
> >   	fsopt->rasize = CEPH_RASIZE_DEFAULT;
> > +	fsopt->snapdir_mode = (umode_t)-1;
> > +	fsopt->snapdir_uid = INVALID_UID;
> > +	fsopt->snapdir_gid = INVALID_GID;
> >   	fsopt->snapdir_name = kstrdup(CEPH_SNAPDIRNAME_DEFAULT, GFP_KERNEL);
> >   	if (!fsopt->snapdir_name)
> >   		goto nomem;
> > diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> > index d44a366b2f1b..3c930816078d 100644
> > --- a/fs/ceph/super.h
> > +++ b/fs/ceph/super.h
> > @@ -85,6 +85,10 @@ struct ceph_mount_options {
> >   	unsigned int max_readdir;       /* max readdir result (entries) */
> >   	unsigned int max_readdir_bytes; /* max readdir result (bytes) */
> > +	umode_t snapdir_mode;
> > +	kuid_t snapdir_uid;
> > +	kgid_t snapdir_gid;
> > +
> >   	bool new_dev_syntax;
> >   	/*
> 

  parent reply	other threads:[~2022-10-11  9:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-27 12:08 [PATCH] fs/ceph/super: add mount options "snapdir{mode,uid,gid}" Max Kellermann
2022-10-09  6:23 ` Xiubo Li
2022-10-09  6:49   ` Max Kellermann
     [not found]     ` <75e7f676-8c85-af0a-97b2-43664f60c811@redhat.com>
2022-10-09 10:27       ` Max Kellermann
2022-10-09 10:28         ` Max Kellermann
2022-10-10  2:02         ` Xiubo Li
2022-10-11  7:19           ` Max Kellermann
2022-10-11 10:45           ` Jeff Layton
2022-10-20  1:29             ` Xiubo Li
2022-10-20 10:13               ` Jeff Layton
2022-10-21  0:47                 ` Xiubo Li
2022-10-25  1:35                 ` Xiubo Li
2022-10-25  7:22                   ` Max Kellermann
2022-10-25  9:10                     ` Xiubo Li
2022-10-25  9:57                       ` Max Kellermann
2022-10-11  9:28   ` Luís Henriques [this message]
2022-10-11  9:56     ` Max Kellermann

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=Y0U3UAjugtpOlJqn@suse.de \
    --to=lhenriques@suse.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max.kellermann@ionos.com \
    --cc=xiubli@redhat.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).