https://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2017-05-17T09:12:42ZCeph RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=911252017-05-17T09:12:42ZFlorian Haas
<ul><li><strong>Category</strong> set to <i>Monitor</i></li><li><strong>Tags</strong> set to <i>security</i></li><li><strong>Release</strong> set to <i>jewel</i></li></ul><p>Just checking: is anyone looking at this? It's arguably a security issue, after all.</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=912032017-05-17T16:10:45ZXiaoxi Chenxiaoxchen@ebay.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>12</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Urgent</i></li></ul> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=912062017-05-17T18:38:53ZGreg Farnumgfarnum@redhat.com
<ul></ul><p>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.</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=912092017-05-17T19:34:02ZFlorian Haas
<ul></ul><p>Same issue even with just <code>rw</code>:</p>
<pre>
# 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
</pre>
<p>Note: both <code>rados get</code> and <code>rados put</code> <strong>do</strong> fail in the <code>test</code> pool, it's just listing objects that succeeds.</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=914572017-05-23T19:37:47ZGreg Farnumgfarnum@redhat.com
<ul><li><strong>Category</strong> changed from <i>Monitor</i> to <i>OSD</i></li></ul><p>Well, it's obvious enough, we go into PrimaryLogPG::do_pg_op() before we check op_has_sufficient_caps().</p>
<p>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?</p>
<p>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.</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=914802017-05-24T08:52:30ZFlorian Haas
<ul></ul><p>For what it's worth, this is a regression. In Hammer, the appropriate EPERM is raised:<br /><pre>
$ rados -n client.libvirt -p .rgw ls
rados returned (1) Operation not permitted
</pre></p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=916192017-05-25T00:16:41ZBrad Hubbardbhubbard@redhat.com
<ul><li><strong>Assignee</strong> set to <i>Brad Hubbard</i></li></ul><p>Looking into this</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=917842017-05-29T23:28:09ZBrad Hubbardbhubbard@redhat.com
<ul></ul><p><a class="external" href="https://github.com/ceph/ceph/pull/15354">https://github.com/ceph/ceph/pull/15354</a></p>
<p>Greg, will talk to you about the per-object cap semantics separately.</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=917852017-05-29T23:30:13ZBrad Hubbardbhubbard@redhat.com
<ul><li><strong>Status</strong> changed from <i>12</i> to <i>In Progress</i></li><li><strong>Backport</strong> set to <i>kraken,jewel</i></li></ul> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=930732017-06-17T06:00:25ZGreg Farnumgfarnum@redhat.com
<ul><li><strong>Project</strong> changed from <i>Ceph</i> to <i>RADOS</i></li><li><strong>Category</strong> changed from <i>OSD</i> to <i>Security</i></li><li><strong>Component(RADOS)</strong> <i>OSD</i> added</li></ul> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=939302017-06-28T15:31:43ZSage Weilsage@newdream.net
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=955832017-07-20T20:03:02ZFlorian Haas
<ul></ul><p>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?</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=955852017-07-20T20:26:56ZNathan Cutlerncutler@suse.cz
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Pending Backport</i></li></ul> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=956132017-07-20T20:28:52ZNathan Cutlerncutler@suse.cz
<ul><li><strong>Copied to</strong> <i><a class="issue tracker-9 status-6 priority-4 priority-default closed" href="/issues/20722">Backport #20722</a>: kraken: rados ls on pool with no access returns no error</i> added</li></ul> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=956152017-07-20T20:28:54ZNathan Cutlerncutler@suse.cz
<ul><li><strong>Copied to</strong> <i><a class="issue tracker-9 status-3 priority-4 priority-default closed" href="/issues/20723">Backport #20723</a>: jewel: rados ls on pool with no access returns no error</i> added</li></ul> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=956422017-07-20T22:52:03ZBrad Hubbardbhubbard@redhat.com
<ul></ul><p>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.</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=956872017-07-21T14:10:24ZFlorian Haas
<ul></ul><p>No worries, thanks for the update!</p> RADOS - Bug #19790: rados ls on pool with no access returns no errorhttps://tracker.ceph.com/issues/19790?journal_id=993012017-09-18T20:57:51ZNathan Cutlerncutler@suse.cz
<ul><li><strong>Status</strong> changed from <i>Pending Backport</i> to <i>Resolved</i></li></ul>