The most secure way would be one in which you can only create pools with
WORM set and can't ever change the WORM state of a pool. I like this
simple/secure approach as a first cut.
David
On 1/17/15 11:09 AM, Alex Elsayed wrote:
Sage Weil wrote:
On Fri, 16 Jan 2015, Alex Elsayed wrote:
Wido den Hollander wrote:
<snip>
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
There's another pool feature I'd find very useful: a WORM flag, that
permits only create & append (at the RADOS level, not the RBD level as
was an Emperor blueprint).
In particular, I'd _love_ being able to make something that takes
Postgres WAL logs and puts them in such a pool, providing real guarantees
re: consistency. Similarly, audit logs and such for compliance.
How would you want this to work?
- If the bit is set, object creates are allowed, but not deletes? What
about append?
- Are you allowed to clear the bit with something like 'ceph osd pool set
<pool> worm false' ?
I'd say that a WORM pool would allow 'create' and 'append' only - that fits
well with the classic notions of WORM media, and would allow natural
implementations of virtualized WORM tape libraries and such for people who
need compatibility (if only object creation was supported, you get issues
where either you have absurd tiny objects or risk data loss on failure to
write a larger buffered chunk). Similarly, audit records (like selinux logs,
that might be written by log daemons) don't really come in nice object-sized
chunks. You want to always have the newest in the archive, so you really
don't want to buffer up to that.
I'd also figure that WORM's main purpose is assurance/compliance - you want
to _know_ that nobody could have turned the bit off, futzed with the data,
and then turned it back on. Otherwise, you'd just write your clients to only
use create/append, and have no need for WORM at the pool level. Because of
that, if the flag can be cleared via commands, it should be possible for the
admins to forbid it (by flat denying it in config, via some keying system,
via the bits being a ratchet, whatever - I'm not especially concerned by how
the guarantee is provided, so long as it can be).
Setting it should probably also be privileged, since it'd be trivial to
cause a DOS by setting it on (say) a CephFS pool - although handling that
concern is likely out-of-scope for now, since there are easier ways to ruin
someone's day at the RADOS level.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
