I don't care what happens to most of these rados commands, and I've never used the auid "functionality", but I have found the rados purge command quite useful when testing different rados level applications. Run a rados-level application test. Whoops it didn't do what you wanted, purge and start over. It is significantly faster than alternative of looping through a 'rados ls' and issuing 'rados rm' for every object. Sure I could delete the pool and recreate one with the same name, but that seems wasteful. Enabling pool deletion in the monitors, allocating new pool ids, causing the mass re-peering of placement groups, making sure the all of the per-pool settings exactly match what you had before. It gets tedious. If the code-path for a purge is different on the server-side, perhaps there could be an additional permission to let the cephx user perform a purge. At least then it is protected from the casual (ab)user. Just my two cents. -- Adam On Sat, Aug 11, 2018 at 1:39 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Fri, 10 Aug 2018, Gregory Farnum wrote: >> On Wed, Aug 8, 2018 at 1:33 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: >> > There is an undocumented part of the cephx authentication framework called >> > the 'auid' (auth uid) that assigns an integer identifier to cephx users >> > and to rados pools and allows you to craft cephx capabilities that apply >> > to those pools. This is leftover infrastructure from an ancient time in >> > which RGW buckets mapped 1:1 to rados pools (pre-argonaut!) and it was >> > expected the cephx capabilities would line up with that. >> > >> > Although in theory parts of the auid infrastructure might work and be in >> > use, it is undocumented, untested, and a messy artifact in the code. I'd >> > like to remove it. >> > >> > *** >> > >> > If you are using auid-based cephx capabilities, now is the time to tell >> > us! Or, if you know of any reason we should keep it around, now is >> > the time to speak up. >> > >> > Otherwise we will remove it! >> > >> > *** >> >> I used to be very proud of this code, but +1. I don't know of any >> users who *could* be using it (much less are) and it really doesn't >> make any sense in our current security architecture even if it might >> function. > > Two questions so far: > > 1) I marked the librados calls that take aui deprecated, but I can wire > them up to still work. For example, if you call pool_create_with_auid it > can still create a pool. Alternatively, I can make those calls now return > EOPNOTSUPP. That could break some wayward librados user, though. > Similarly, there are calls to get and set the pool auid. Currently I have > converted to no-ops, but they could also return an error instead. > Thoughts? > > 2) The rados cli has a 'mkpool' command that works like 'rados mkpool > <poolname> [auid [crush-rule]]'. The ordering means I can't just drop > auid. So, I could ignore the auid argument, or change the calling > convention completely. > > Or, we could remove the command completely and let people use 'ceph osd > pool create' for this. This is my preference! In fact, there are > several commands I'd suggest killing at the same time: > > " mkpool <pool-name> [123[ 4]] create pool <pool-name>'\n" > " [with auid 123[and using crush rule > 4]]\n" > " cppool <pool-name> <dest-pool> copy content of a pool\n" > " rmpool <pool-name> [<pool-name> --yes-i-really-really-mean-it]\n" > " remove pool <pool-name>'\n" > " purge <pool-name> --yes-i-really-really-mean-it\n" > " remove all objects from pool > <pool-name> without removing it\n" > > cppool is an imcomplete implementation anyway (doesn't preserve snaps, > for example; prabably doesn't do omap either?). The others just scare me. > > Thoughts? > sage > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |