From: Alexandre Marangone Date: Mon, 23 Mar 2015 23:36:08 +0000 (-0700) Subject: be gender neutral X-Git-Tag: v9.0.0~104 X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=7f03c8891a94f0cdacec4256407dee2668b2af2c;p=ceph.git be gender neutral Signed-off-by: Alexandre Marangone Reviewed-by: Sage Weil --- diff --git a/SubmittingPatches b/SubmittingPatches index 2a1658737ea53..130f97756c9d8 100644 --- a/SubmittingPatches +++ b/SubmittingPatches @@ -73,7 +73,7 @@ exactly the same in your tree and the submitters'. If you stick strictly to 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 diff --git a/doc/dev/cephx_protocol.rst b/doc/dev/cephx_protocol.rst index d6560c12e467d..c514b38eb00df 100644 --- a/doc/dev/cephx_protocol.rst +++ b/doc/dev/cephx_protocol.rst @@ -18,18 +18,18 @@ The basic idea of the protocol is based on Kerberos. A client wishes to obtain 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 @@ -45,11 +45,11 @@ the system. 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 @@ -59,7 +59,7 @@ known only to A and C. 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 @@ -141,18 +141,18 @@ We now call the same routine the client used to calculate the hash, based on 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()``. @@ -181,13 +181,13 @@ filled in. There's a global ID that comes up as a result of this fiddling that 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``, @@ -240,12 +240,12 @@ put it in the buffer provided in the call to ``cephx_verify_authorizer()`` and r 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 @@ -314,22 +314,22 @@ we need, since we now have a ticket we didn't have before. If we've taken care 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. diff --git a/doc/dev/peering.rst b/doc/dev/peering.rst index ed40589ba195b..63574cac49dbe 100644 --- a/doc/dev/peering.rst +++ b/doc/dev/peering.rst @@ -169,20 +169,20 @@ The high level process is for the current PG primary to: 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. @@ -193,8 +193,8 @@ The high level process is for the current PG primary to: 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. diff --git a/doc/dev/session_authentication.rst b/doc/dev/session_authentication.rst index fd2651dd05d6c..e8a5059c69e39 100644 --- a/doc/dev/session_authentication.rst +++ b/doc/dev/session_authentication.rst @@ -5,7 +5,7 @@ Peter Reiher 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. diff --git a/doc/rados/operations/user-management.rst b/doc/rados/operations/user-management.rst index de43e18b5e9bb..287fb333b47f2 100644 --- a/doc/rados/operations/user-management.rst +++ b/doc/rados/operations/user-management.rst @@ -641,7 +641,7 @@ authentication issues more fully. 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 diff --git a/src/include/Context.h b/src/include/Context.h index 2ae92214b7242..01214f637550c 100644 --- a/src/include/Context.h +++ b/src/include/Context.h @@ -191,7 +191,7 @@ public: } 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) { diff --git a/src/mds/Migrator.cc b/src/mds/Migrator.cc index e1f8ce8873ed5..86e10feb3b157 100644 --- a/src/mds/Migrator.cc +++ b/src/mds/Migrator.cc @@ -1905,7 +1905,7 @@ void Migrator::handle_export_discover(MExportDirDiscover *m) 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. diff --git a/src/mon/Elector.h b/src/mon/Elector.h index f989bd5de5a0d..f2ac66cc3fb8c 100644 --- a/src/mon/Elector.h +++ b/src/mon/Elector.h @@ -127,7 +127,7 @@ class Elector { */ int leader_acked; /** - * Indicates when we have acked him + * Indicates when we have acked it */ utime_t ack_stamp; /** @@ -245,7 +245,7 @@ class Elector { 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), @@ -253,16 +253,16 @@ class Elector { * * @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 * * diff --git a/src/mon/PGMonitor.cc b/src/mon/PGMonitor.cc index e699efb652b7b..a1ffcb1904c8b 100644 --- a/src/mon/PGMonitor.cc +++ b/src/mon/PGMonitor.cc @@ -1193,7 +1193,7 @@ void PGMonitor::send_pg_creates(int osd, Connection *con) 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; } diff --git a/src/mon/Paxos.cc b/src/mon/Paxos.cc index 95b35388453ea..9c85ced52bfe5 100644 --- a/src/mon/Paxos.cc +++ b/src/mon/Paxos.cc @@ -292,7 +292,7 @@ void Paxos::handle_collect(MMonPaxos *collect) /** * @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 diff --git a/src/mon/Paxos.h b/src/mon/Paxos.h index 769dca0a55996..12b35db72eb25 100644 --- a/src/mon/Paxos.h +++ b/src/mon/Paxos.h @@ -453,7 +453,7 @@ private: * * 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. */ @@ -463,7 +463,7 @@ private: * * 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. * @@ -764,14 +764,14 @@ private: * * 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. */ @@ -859,7 +859,7 @@ private: * @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 * @@ -1152,7 +1152,7 @@ public: * 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. */