rule (c), you should ask the submitter to rediff, but this is a totally
counter-productive waste of time and energy. Rule (b) allows you to adjust
the code, but then it is very impolite to change one submitter's code and
-make him endorse your bugs. To solve this problem, it is recommended that
+make them endorse your bugs. To solve this problem, it is recommended that
you add a line between the last Signed-off-by header and yours, indicating
the nature of your changes. While there is nothing mandatory about this, it
seems like prepending the description with your mail and/or name, all
a server. The server will only offer the requested service to authorized clients. Rather
than requiring each server to deal with authentication and authorization issues, the system
uses an authorization server. Thus, the client must first communicate with the authorization
-server to authenticate himself and to obtain credentials that will grant him access to the
-service he wants.
+server to authenticate itself and to obtain credentials that will grant it access to the
+service it wants.
Authorization is not the same as authentication. Authentication provides evidence that some
-party is who he claims to be. Authorization provides evidence that a particular party is
+party is who it claims to be. Authorization provides evidence that a particular party is
allowed to do something. Generally, secure authorization implies secure authentication
(since without authentication, you may authorize something for an imposter), but the reverse
is not necessarily true. One can authenticate without authorizing. The purpose
of this protocol is to authorize.
-The basic approach is to use symmetric cryptography throughout. Each client C has his own
-secret key, known only to himself and the authorization server A. Each server S has its own
+The basic approach is to use symmetric cryptography throughout. Each client C has its own
+secret key, known only to itself and the authorization server A. Each server S has its own
secret key, known only to itself and the authorization server A. Authorization information
will be passed in tickets, encrypted with the secret key of the entity that offers the service.
There will be a ticket that A gives to C, which permits C to ask A for other tickets. This
Several parties need to prove something to each other if this protocol is to achieve its
desired security effects.
-1. The client C must prove to the authenticator A that he really is C. Since everything
+1. The client C must prove to the authenticator A that it really is C. Since everything
is being done via messages, the client must also prove that the message proving authenticity
is fresh, and is not being replayed by an attacker.
-2. The authenticator A must prove to client C that he really is the authenticator. Again,
+2. The authenticator A must prove to client C that it really is the authenticator. Again,
proof that replay is not occurring is also required.
3. A and C must securely share a session key to be used for distribution of later
4. A must receive evidence from C that allows A to look up C's authorized operations with
server S.
-5. C must receive a ticket from A that will prove to S that C can perform his authorized
+5. C must receive a ticket from A that will prove to S that C can perform its authorized
operations. This ticket must be usable only by C.
6. C must receive from A a session key to protect the communications between C and S. The
the client challenge (which is in the incoming message), the server challenge (which we saved),
and the client's key (which we just obtained). We check to see if the client sent the same
thing we expected. If so, we know we're talking to the right client. We know the session is
-fresh, because he used the challenge we sent him to calculate his crypto hash. So we can
-give him an authentication ticket.
+fresh, because it used the challenge we sent it to calculate its crypto hash. So we can
+give it an authentication ticket.
We fetch C's ``eauth`` structure. This contains an ID, a key, and a set of caps (capabilities).
-The client sent us his old ticket in the message, if he had one. If so, we set a flag,
+The client sent us its old ticket in the message, if it had one. If so, we set a flag,
``should_enc_ticket``, to true and set the global ID to the global ID in that old ticket.
-If the attempt to decode his old ticket fails (most probably because he didn't have one),
+If the attempt to decode its old ticket fails (most probably because it didn't have one),
``should_enc_ticket`` remains false. Now we set up the new ticket, filling in timestamps,
the name of C, the global ID provided in the method call (unless there was an old ticket), and
his ``auid``, obtained from the ``eauth`` structure obtained above. We need a new session key
-to help the client communicate securely with us, not using his permanent key. We set the
+to help the client communicate securely with us, not using its permanent key. We set the
service ID to ``CEPH_ENTITY_TYPE_AUTH``, which will tell the client C what to do with the
message we send it. We build a cephx response header and call
``cephx_build_service_ticket_reply()``.
the reply message. The reply message is built here (mostly from the ``response_bl`` buffer)
and sent off.
-This completes Phase I of the protocol. At this point, C has authenticated himself to A, and A has generated a new session key and ticket allowing C to obtain server tickets from A.
+This completes Phase I of the protocol. At this point, C has authenticated itself to A, and A has generated a new session key and ticket allowing C to obtain server tickets from A.
Phase II
--------
This phase starts when C receives the message from A containing a new ticket and session key.
-The goal of this phase is to provide A with a session key and ticket allowing him to
+The goal of this phase is to provide A with a session key and ticket allowing it to
communicate with S.
The message A sent to C is dispatched to ``build_request()`` in ``CephxClientHandler.cc``,
to ``handle`_request()``. This will be used to prove to C that A (rather than an attacker)
created this response.
-Having verified that the message is valid and from C, now we need to build him a ticket for S.
-We need to know what S he wants to communicate with and what services he wants. Pull the
-ticket request that describes those things out of his message. Now run through the ticket
-request to see what he wanted. (He could potentially be asking for multiple different
+Having verified that the message is valid and from C, now we need to build it a ticket for S.
+We need to know what S it wants to communicate with and what services it wants. Pull the
+ticket request that describes those things out of its message. Now run through the ticket
+request to see what it wanted. (He could potentially be asking for multiple different
services in the same request, but we will assume it's just one, for this discussion.) Once we
-know which service ID he's after, call ``build_session_auth_info()``.
+know which service ID it's after, call ``build_session_auth_info()``.
``build_session_auth_info()`` is in ``CephxKeyServer.cc``. It checks to see if the
secret for the ``service_ID`` of S is available and puts it into the subfield of one of
everything we need, we'll return 0.
This ends phase II of the protocol. We have now successfully set up a ticket and session key
-for client C to talk to server S. S will know that C is who he claims to be, since A will
-verify it. C will know it is S he's talking to, again because A verified it. The only
+for client C to talk to server S. S will know that C is who it claims to be, since A will
+verify it. C will know it is S it's talking to, again because A verified it. The only
copies of the session key for C and S to communicate were sent encrypted under the permanent
keys of C and S, respectively, so no other party (excepting A, who is trusted by all) knows
that session key. The ticket will securely indicate to S what C is allowed to do, attested
to by A. The nonces passed back and forth between A and C ensure that they have not been
-subject to a replay attack. C has not yet actually talked to S, but he is ready to.
+subject to a replay attack. C has not yet actually talked to S, but it is ready to.
Much of the security here falls apart if one of the permanent keys is compromised. Compromise
of C's key means that the attacker can pose as C and obtain all of C's privileges, and can
eavesdrop on C's legitimate conversations. He can also pretend to be A, but only in
-conversations with C. Since he does not (by hypothesis) have keys for any services, he
-cannot generate any new tickets for services, though he can replay old tickets and session
+conversations with C. Since it does not (by hypothesis) have keys for any services, he
+cannot generate any new tickets for services, though it can replay old tickets and session
keys until S's permanent key is changed or the old tickets time out.
Compromise of S's key means that the attacker can pose as S to anyone, and can eavesdrop on
any user's conversation with S. Unless some client's key is also compromised, the attacker
-cannot generate new fake client tickets for S, since doing so requires him to authenticate
-himself as A, using the client key he doesn't know.
+cannot generate new fake client tickets for S, since doing so requires it to authenticate
+himself as A, using the client key it doesn't know.
we learn about a *last epoch started* that is newer than our own, we can
prune older *past intervals* and reduce the peer OSDs we need to contact.
- 5. if anyone else has (in his PG log) operations that I do not have,
+ 5. if anyone else has (in its PG log) operations that I do not have,
instruct them to send me the missing log entries so that the primary's
*PG log* is up to date (includes the newest write)..
5. for each member of the current *acting set*:
- a) ask him for copies of all PG log entries since *last epoch start*
+ a) ask it for copies of all PG log entries since *last epoch start*
so that I can verify that they agree with mine (or know what
- objects I will be telling him to delete).
+ objects I will be telling it to delete).
If the cluster failed before an operation was persisted by all
members of the *acting set*, and the subsequent *peering* did not
remember that operation, and a node that did remember that
- operation later rejoined, his logs would record a different
+ operation later rejoined, its logs would record a different
(divergent) history than the *authoritative history* that was
reconstructed in the *peering* after the failure.
any OSD that stores data from a divergent update to delete the
affected (and now deemed to be apocryphal) objects.
- b) ask him for his *missing set* (object updates recorded
- in his PG log, but for which he does not have the new data).
+ b) ask it for its *missing set* (object updates recorded
+ in its PG log, but for which it does not have the new data).
This is the list of objects that must be fully replicated
before we can accept writes.
7/30/12
The original Cephx protocol authenticated the client to the authenticator and set up a session
-key used to authenticate the client to the server he needs to talk to. It did not, however,
+key used to authenticate the client to the server it needs to talk to. It did not, however,
authenticate the ongoing messages between the client and server. Based on the fact that they
share a secret key, these ongoing session messages can be easily authenticated by using the
key to sign the messages.
At the moment, none of the Ceph authentication protocols provide secrecy for
messages in transit. Thus, an eavesdropper on the wire can hear and understand
-all data sent between clients and servers in Ceph, even if he cannot create or
+all data sent between clients and servers in Ceph, even if it cannot create or
alter them. Further, Ceph does not include options to encrypt user data in the
object store. Users can hand-encrypt and store their own data in the Ceph
object store, of course, but Ceph provides no features to perform object
}
void complete(int r) {
// Neuter any ContextInstanceType custom complete(), because although
- // I want to look like him, I don't actually want to run his code.
+ // I want to look like it, I don't actually want to run its code.
Context::complete(r);
}
void finish(int r) {
if (r > 0) return;
if (r < 0) {
dout(7) << "handle_export_discover_2 failed to discover or not dir " << m->get_path() << ", NAK" << dendl;
- assert(0); // this shouldn't happen if the auth pins his path properly!!!!
+ assert(0); // this shouldn't happen if the auth pins its path properly!!!!
}
assert(0); // this shouldn't happen; the get_inode above would have succeeded.
*/
int leader_acked;
/**
- * Indicates when we have acked him
+ * Indicates when we have acked it
*/
utime_t ack_stamp;
/**
void victory();
/**
- * Handle a message from some other node proposing himself to become him
+ * Handle a message from some other node proposing itself to become it
* the Leader.
*
* If the message appears to be old (i.e., its epoch is lower than our epoch),
*
* @li Ignore it because it's nothing more than an old proposal
* @li Start new elections if we verify that it was sent by a monitor from
- * outside the quorum; given its old state, it's fair to assume he just
- * started, so we should start new elections so he may rejoin
+ * outside the quorum; given its old state, it's fair to assume it just
+ * started, so we should start new elections so it may rejoin
*
* If we did not ignore the received message, then we know that this message
- * was sent by some other node proposing himself to become the Leader. So, we
+ * was sent by some other node proposing itself to become the Leader. So, we
* will take one of the following actions:
*
- * @li Ignore him because we already acked another node with higher rank
- * @li Ignore him and start a new election because we outrank him
- * @li Defer to him because he outranks us and the node we previously
+ * @li Ignore it because we already acked another node with higher rank
+ * @li Ignore it and start a new election because we outrank it
+ * @li Defer to it because it outranks us and the node we previously
* acked, if any
*
*
m->mkpg[*q] = pg_create_t(pg_map.pg_stat[*q].created,
pg_map.pg_stat[*q].parent,
pg_map.pg_stat[*q].parent_split_bits);
- // Need the create time from the monitor using his clock to set last_scrub_stamp
+ // Need the create time from the monitor using its clock to set last_scrub_stamp
// upon pg creation.
m->ctimes[*q] = pg_map.pg_stat[*q].last_scrub_stamp;
}
/**
* @note This is Okay. We share our versions between peer_last_committed and
* our last_committed (inclusive), and add their bufferlists to the
- * message. It will be the peer's job to apply them to his store, as
+ * message. It will be the peer's job to apply them to its store, as
* these bufferlists will contain raw transactions.
* This function is called by both the Peon and the Leader. The Peon will
* share the state with the Leader during handle_collect(), sharing any
*
* We use this variable to assess if the Leader should take into consideration
* an uncommitted value sent by a Peon. Given that the Peon will send back to
- * the Leader the last Proposal Number he accepted, the Leader will be able
+ * the Leader the last Proposal Number it accepted, the Leader will be able
* to infer if this value is more recent than the one the Leader has, thus
* more relevant.
*/
*
* If the system fails in-between the accept replies from the Peons and the
* instruction to commit from the Leader, then we may end up with accepted
- * but yet-uncommitted values. During the Leader's recovery, he will attempt
+ * but yet-uncommitted values. During the Leader's recovery, it will attempt
* to bring the whole system to the latest state, and that means committing
* past accepted but uncommitted values.
*
*
* Once a Peon receives a collect message from the Leader it will reply
* with its first and last committed versions, as well as information so
- * the Leader may know if his Proposal Number was, or was not, accepted by
+ * the Leader may know if its Proposal Number was, or was not, accepted by
* the Peon. The Peon will accept the Leader's Proposal Number iif it is
* higher than the Peon's currently accepted Proposal Number. The Peon may
* also inform the Leader of accepted but uncommitted values.
*
* @invariant The message is an operation of type OP_COLLECT.
* @pre We are a Peon.
- * @post Replied to the Leader, accepting or not accepting his PN.
+ * @post Replied to the Leader, accepting or not accepting its PN.
*
* @param collect The collect message sent by the Leader to the Peon.
*/
* @pre We are a Peon
* @pre We are on STATE_ACTIVE
* @post We are on STATE_UPDATING iif we accept the Leader's proposal
- * @post We send a reply message to the Leader iif we accept his proposal
+ * @post We send a reply message to the Leader iif we accept its proposal
*
* @invariant The received message is an operation of type OP_BEGIN
*
* quorum, thus automatically assume we are on STATE_RECOVERING, which means
* we will soon be enrolled into the Leader's collect phase.
*
- * @pre There is a Leader, and he's about to start the collect phase.
+ * @pre There is a Leader, and it?s about to start the collect phase.
* @post We are on STATE_RECOVERING and will soon receive collect phase's
* messages.
*/
projects / ceph.git / commitdiff