module Nn_datanode_ctrl:Manage tickets and push ticket secrets to the datanodessig
..end
val reset : unit -> unit
type
ticket_verifier = {
|
tv_safetrans_id : |
|
tv_safetrans_tmo : |
|
tv_safetrans_sec : |
|
tv_datanodes : |
|
tv_enabled : |
Nn_alloc_types.transacted_datastores
val new_ticket_verifier : unit -> ticket_verifier
val enable_ticket_verifier_e : ticket_verifier -> unit Uq_engines.engine
val disable_ticket_verifier_e : ticket_verifier -> unit Uq_engines.engine
val disconnect : int -> unit
val post_start_hook : unit -> unit
disable_ticket_verifier_e
does not disable the verifier
immediately, but delays this to the next round of housekeeping -
which usually happens once every second.
There is a security risk here: The verifier remains valid even after the transaction is closed. Although this is only for a very short period of time, this can be abused by a malicious user.
The cure (only to be implemented once we secure everything): The verifier can be used to access blocks. There is no problem when only the blocks are accessed for which the ticket was originally valid, i.e. the blocks of the accessed files. The security hole exists only when these blocks are reused for other files - the verifier would then grant access to these other files although there is actually no permission.
So the idea is to prevent that blocks are reused for other files until the verifier is really cancelled. We already have a mechanism - the blocks need to be tagged with the "keep" method of the blockmaps. Such blocks are not freed as long as the tag remains.
So:
post_commit
hook of the blockmap view, we look for newly
allocated blocks. These blocks are not only committed/aborted as usual,
but additionally they are tagged with keep
(the owner may
be an arbitrary object, maybe passed down from the transaction)disable_ticket_verifier_e
gets an additional callback: it is
invoked when the verifier has really been invalidated.