Bug #19790
closed
rados ls on pool with no access returns no error
Added by Florian Haas about 7 years ago.
Updated over 6 years ago.
Description
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)
- Category set to Monitor
- Tags set to security
- Release set to jewel
Just checking: is anyone looking at this? It's arguably a security issue, after all.
- Status changed from New to 12
- Priority changed from Normal to Urgent
I'm not at a computer to check, but I'm pretty sure the "allow *" is short-circuiting other security checks here and letting it do whatever it wants. Try with rwx instead.
Same issue even with just rw:
# 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
Note: both rados get and rados put do fail in the test pool, it's just listing objects that succeeds.
- 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.
For what it's worth, this is a regression. In Hammer, the appropriate EPERM is raised:
$ rados -n client.libvirt -p .rgw ls
rados returned (1) Operation not permitted
- Assignee set to Brad Hubbard
- Status changed from 12 to In Progress
- Backport set to kraken,jewel
- Project changed from Ceph to RADOS
- Category changed from OSD to Security
- Component(RADOS) OSD added
- Status changed from In Progress to Resolved
Thanks a lot for the fix in master/luminous, taking the liberty to follow up on this one — looks like the backport to Jewel is still pending. Is this still in the cards?
- Status changed from Resolved to Pending Backport
- Copied to Backport #20722: kraken: rados ls on pool with no access returns no error added
- Copied to Backport #20723: jewel: rados ls on pool with no access returns no error added
Looks like we may have set the wrong state on this tracker and therefore overlooked it for the purposes of backporting. It looks like Nathan has set this straight now, sorry for the delay.
No worries, thanks for the update!
- Status changed from Pending Backport to Resolved
Also available in: Atom
PDF