Re: 'Immutable bit' on pools to prevent deletion

[Wido den Hollander <wido@42on.com>]

On 01/15/2015 04:39 PM, Dan Van Der Ster wrote:
> Hi Wido,
> 
> +1 for safeguards.
> 
> Yeah that is scary: it's one api call to delete a pool, and perhaps even a client with w capability on a pool can delete it?? (I didn’t try...)
> 

Quick try, yes! Created a pool and user which only has access to that
pool. I was able to remove that pool.

> I can think of many ways that fat fingers can create crazy loads, deny client access, ...
> 

Sure, but none of those actually make you loose your data.

I know that you should create backups, but by accident removing a pool
is something that is very dangerous and it will take a lot of time to
restore from backups.

>  1. changing pool size
>  2. setting pool quotas
>  3. unplanned PG splitting
>  4. creating an EC pool on a cluster with dumpling clients
>  5. reweight-by-utilization
>  6. changing crush rules/tunables
> 
> —yes-i-really-really-mean-it is nice when it’s there. But regardless it is probably not a good practice to work daily (or run librados cron jobs) in a shell that has access to the client.admin keyring. I’ve thought of using sudo to restrict our admin shell to subset of ceph admin commands. But even better would be a internal bit which locks out the API beneath “ceph osd pool …” and “ceph osd crush …”, even for client.admin.
> 
> Maybe this is already possible by creating a client.admin-readonly account for daily work and crons, and limit access to client.admin except when absolutely necessary ?
> 

That would be great indeed. The client.admin key currently has all the
capabilities and I would indeed like a RO account.

But still, another safeguard against deleting pools would be something
I'd like to see.

Wido

> Cheers, Dan
> 
> 
>> On 15 Jan 2015, at 15:46, Wido den Hollander <wido@42on.com> wrote:
>>
>> Hi,
>>
>> Although the userland tools like 'ceph' and 'rados' have a safeguard
>> against fat fingers when it comes to removing a pool there is no such
>> safeguard when using native librados.
>>
>> The danger still exists that by accident you remove a pool which is then
>> completely gone, no way to restore it.
>>
>> This is still something I find quite dangerous, so I was thinking about
>> a additional 'Immutable bit' which could be set on a pool before
>> rados_pool_delete() allows this pool to be removed.
>>
>> Is it a sane thing to look at 'features' which pools could have? Other
>> features which might be set on a pool:
>>
>> - Read Only (all write operations return -EPERM)
>> - Delete Protected
>>
>> It's just that looking at a 20TB RBD pool and thinking that just one API
>> call could remove this pool make me a bit scared.
>>
>> Am I the only one or is this something worth looking in to?
>>
>> -- 
>> Wido den Hollander
>> 42on B.V.
>> Ceph trainer and consultant
>>
>> Phone: +31 (0)20 700 9902
>> Skype: contact42on
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Wido den Hollander
42on B.V.
Ceph trainer and consultant

Phone: +31 (0)20 700 9902
Skype: contact42on
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html