be gender neutral

Signed-off-by: Alexandre Marangone <amarango@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>

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

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 
+server to authenticate itself and to obtain credentials that will grant it access to the
-service he wants. 
+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 
+The basic approach is to use symmetric cryptography throughout.  Each client C has its own
-secret key, known only to himself and the authorization server A.  Each server S 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 
+fresh, because it used the challenge we sent it to calculate its crypto hash.  So we can
-give him an authentication ticket.
+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.  
+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 he wants to communicate with and what services he wants.  Pull the 
+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 his message.  Now run through the ticket 
+ticket request that describes those things out of its message.  Now run through the ticket
-request to see what he wanted.  (He could potentially be asking for multiple different 
+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 
+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 he's talking to, again because A verified it.  The only
+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
+conversations with C.  Since it 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
+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
+cannot generate new fake client tickets for S, since doing so requires it to authenticate
-himself as A, using the client key he doesn't know.
+himself as A, using the client key it doesn't know.

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
+     b) ask it for its *missing set* (object updates recorded
-	in his PG log, but for which he does not have the new data).
+	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.
 

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.  

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

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) {

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.

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
+   *	  outside the quorum; given its old state, it's fair to assume it just
-   *	  started, so we should start new elections so he may rejoin
+   *	  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 it because we already acked another node with higher rank
-   *  @li Ignore him and start a new election because we outrank him
+   *  @li Ignore it and start a new election because we outrank it
-   *  @li Defer to him because he outranks us and the node we previously
+   *  @li Defer to it because it outranks us and the node we previously
    *	  acked, if any
    *
    *

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;
   }

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

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.
    */