From: Max Kellermann <max.kellermann@ionos.com>
To: Xiubo Li <xiubli@redhat.com>
Cc: Jeff Layton <jlayton@kernel.org>,
idryomov@gmail.com, 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, 25 Oct 2022 09:22:59 +0200 [thread overview]
Message-ID: <CAKPOu+_Jk0EHRDjqiNuFv8wL0kLXLLRZpx7AgWDPOWHzJn22xg@mail.gmail.com> (raw)
In-Reply-To: <7d40fada-f5f8-4357-c559-18421266f5b4@redhat.com>
On Tue, Oct 25, 2022 at 3:36 AM Xiubo Li <xiubli@redhat.com> wrote:
> Currently cephx permission has already supported the 's' permission,
> which means you can do the snapshot create/remove. And for a privileged
> or specific mounts you can give them the 's' permission and then only
> they can do the snapshot create/remove. And all the others won't.
But that's a client permission, not a user permission.
I repeat: the problem is that snapshots should only be
accessible/discoverable/creatable by certain users (UIDs/GIDs) on the
client machine, independent of their permission on the parent
directory.
My patch decouples parent directory permissions from snapdir
permissions, and it's a simple and elegant solution to my problem.
> And then use the container or something else to make the specific users
> could access to them.
Sorry, I don't get it at all. What is "the container or something" and
how does it enable me to prevent specific users from accessing
snapdirs in their home directories?
next prev parent reply other threads:[~2022-10-25 7:23 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 [this message]
2022-10-25 9:10 ` Xiubo Li
2022-10-25 9:57 ` Max Kellermann
2022-10-11 9:28 ` Luís Henriques
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=CAKPOu+_Jk0EHRDjqiNuFv8wL0kLXLLRZpx7AgWDPOWHzJn22xg@mail.gmail.com \
--to=max.kellermann@ionos.com \
--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=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).