Project

General

Profile

Actions

Feature #56428

open

add command "fs deauthorize"

Added by Rishabh Dave almost 2 years ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
% Done:

0%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Component(FS):
Labels (FS):
Pull request ID:

Description

Since entity auth keyrings can now hold auth caps for multiple Ceph FSs, it is very tedious and very error-prone to remove caps for a single FS from the keyring. Here's an example from vstart cluster I locally have -

build$ ./bin/ceph fs ls
name: a, metadata pool: cephfs.a.meta, data pools: [cephfs.a.data ]
name: b, metadata pool: cephfs.b.meta, data pools: [cephfs.b.data ]
name: c, metadata pool: cephfs.c.meta, data pools: [cephfs.c.data ]
name: d, metadata pool: cephfs.d.meta, data pools: [cephfs.d.data ]
build$ ./bin/ceph auth get client.x
[client.x]
        key = AQD8TMpgdaLvEBAAS1IDcMDvIGt1Yw2NYKtjeg==
        caps mds = "allow rw fsname=a, allow rw fsname=b, allow rw
fsname=c, allow rw fsname=d" 
        caps mon = "allow r fsname=a, allow r fsname=b, allow r
fsname=c, allow r fsname=d" 
        caps osd = "allow rw tag cephfs data=a, allow rw tag cephfs
data=b, allow rw tag cephfs data=c, allow rw tag cephfs data=d" 
exported keyring for client.x

The only current way to do it is to use ceph auth caps command and pass all the new caps -

build$ ./bin/ceph auth caps client.x mon "allow r fsname=a, allow r
fsname=b, allow r fsname=c" osd "allow rw tag cephfs data=a, allow rw
tag cephfs data=b, allow rw tag cephfs data=c" mds "allow rw fsname=a,
allow rw fsname=b, allow rw fsname=c" 
updated caps for client.x
build$ ./bin/ceph auth get client.x
[client.x]
        key = AQD8TMpgdaLvEBAAS1IDcMDvIGt1Yw2NYKtjeg==
        caps mds = "allow rw fsname=a, allow rw fsname=b, allow rw fsname=c" 
        caps mon = "allow r fsname=a, allow r fsname=b, allow r fsname=c" 
        caps osd = "allow rw tag cephfs data=a, allow rw tag cephfs
data=b, allow rw tag cephfs data=c" 
exported keyring for client.x

The other way of doing this is to copy the keyring to a file, modify that file and pass the file path to ceph auth import -i. But what would make it really short and straightforward, IMO, is something like following -

./bin/ceph fs deauthorize d client.x

It would have exactly the same effect as the ceph auth caps command above. I think it would also be a good idea to extend this command to take a path -

./bin/ceph fs deauthorize d client.x /dir1/dir2/

In this case, the command would remove only the caps for path /dir1/dir2 for FS "d" from the keyring for the entity "client.x". Every other cap for client.x (both for FS "d" and not for FS "d") would remain unaffected.


Related issues 1 (0 open1 closed)

Related to CephFS - Feature #47264: "fs authorize" subcommand should work for multiple FSs tooResolvedRishabh Dave

Actions
Actions #1

Updated by Rishabh Dave almost 2 years ago

  • Related to Feature #47264: "fs authorize" subcommand should work for multiple FSs too added
Actions #2

Updated by Greg Farnum almost 2 years ago

Hmm, I've had concerns about interfaces like this in the past. What happens if:

caps mds = "allow rw fsname=a, allow rw fsname=b, allow rw fsname=c"

and a user runs

./bin/ceph fs deauthorize a client.x /dir1/dir2/
?

What happens if the user runs
./bin/ceph fs deauthorize d client.x
(note that it doesn't have caps on d)? Keep in mind that under some cluster conditions monitor commands can get resubmitted and need to have the same return value on success as they do on "that value doesn't exist".

What about if
caps mds = "allow rw, allow rw fsname=a, allow rw fsname=b, allow rw fsname=c"
and the user runs
./bin/ceph fs deauthorize a client.x
? We can remove the "fsname=a" clause, but the user can still access fs a due to the "allow rw" clause.

We can solve some of this by having an interface that instead looks like
./bin/ceph fs authorize rm "allow rw" client.x
./bin/ceph fs authorize rm "allow rw fsname=a" client.x
where the admin has to specify a specific clause that gets removed. That at least doesn't imply that returning success means the keyring can't access a given piece of data any more. But I'm not convinced it's worth the headache or helps users that much when it's formulated this way.

Actions #3

Updated by Venky Shankar 5 months ago

  • Target version set to v19.0.0

Hey Rishabh,

As we spoke yesterday, please update here with details of the discussion you has with Greg.

Actions

Also available in: Atom PDF