Bug #19790
closedrados ls on pool with no access returns no error
0%
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)
Updated by Florian Haas almost 7 years ago
- 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.
Updated by Xiaoxi Chen almost 7 years ago
- Status changed from New to 12
- Priority changed from Normal to Urgent
Updated by Greg Farnum almost 7 years ago
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.
Updated by Florian Haas almost 7 years ago
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.
Updated by Greg Farnum almost 7 years 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.
Updated by Florian Haas almost 7 years ago
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
Updated by Brad Hubbard almost 7 years ago
https://github.com/ceph/ceph/pull/15354
Greg, will talk to you about the per-object cap semantics separately.
Updated by Brad Hubbard almost 7 years ago
- Status changed from 12 to In Progress
- Backport set to kraken,jewel
Updated by Greg Farnum almost 7 years ago
- Project changed from Ceph to RADOS
- Category changed from OSD to Security
- Component(RADOS) OSD added
Updated by Sage Weil almost 7 years ago
- Status changed from In Progress to Resolved
Updated by Florian Haas over 6 years ago
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?
Updated by Nathan Cutler over 6 years ago
- Status changed from Resolved to Pending Backport
Updated by Nathan Cutler over 6 years ago
- Copied to Backport #20722: kraken: rados ls on pool with no access returns no error added
Updated by Nathan Cutler over 6 years ago
- Copied to Backport #20723: jewel: rados ls on pool with no access returns no error added
Updated by Brad Hubbard over 6 years ago
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.
Updated by Nathan Cutler over 6 years ago
- Status changed from Pending Backport to Resolved