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.


On Sat, Aug 11, 2018 at 1:39 PM, Sage Weil <s...@newdream.net> wrote:
> On Fri, 10 Aug 2018, Gregory Farnum wrote:
>> On Wed, Aug 8, 2018 at 1:33 PM, Sage Weil <s...@newdream.net> 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@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
ceph-users mailing list

Reply via email to