rados ls on pool with no access returns no error
Given the following auth capabilities:
client.jane key: AQCGsAFZMzgoFhAAr/qnglmIzxJoDwwSV2e4zg== caps: [mon] allow r caps: [osd] allow * pool=whirlpool
... the expectation is that "rados ls" would fail on any pool other than "whirlpool". It does not:
$ rados -n client.jane -p test ls; echo $? testobj0 0
ceph version 10.2.7 (50e863e0f4bc8f4b9e31156de690d765af245185)
#4 Updated by Florian Haas 10 months ago
Same issue even with just
# ceph auth get client.jane exported keyring for client.jane [client.jane] key = AQB9DhxZWVW1NRAA4ELXsaIK13yFPPnCfEsaaA== caps mon = "allow r" caps osd = "allow rw pool=whirlpool" # rados -p test -n client.jane ls testobj
rados get and
rados put do fail in the
test pool, it's just listing objects that succeeds.
#5 Updated by Greg Farnum 10 months ago
- Category changed from Monitor to OSD
Well, it's obvious enough, we go into PrimaryLogPG::do_pg_op() before we check op_has_sufficient_caps().
I think there may be some issues with translating between the usual per-object cap semantics and the pg listing that need to be dealt with though. ie, what happens if they run a listing but can only look at keys with a certain prefix?
I think at that point we probably just deny the listing, but it's not coded up yet. I may get around to this eventually but if somebody else wants to it's a pretty self-contained bit of code.