Change label to 'Jenkins user database'

content/_data/changelogs/weekly.yml

@@ -21705,7 +21705,7 @@
           - url: https://github.com/jenkinsci/jep/blob/master/jep/237/README.adoc
             title: JEP-237
         message: |-
-          Developer: Optionally support a FIPS140 compliant algorithm in the Jenkins' own user database.
+          Developer: Optionally support a FIPS140 compliant algorithm in the Jenkins user database.
 
   # pull: 8546 (PR title: Bump commons-io:commons-io from 2.13.0 to 2.14.0)
   # pull: 8554 (PR title: Actually adjust copy button logic to new API)

content/doc/book/security/access-control.adoc

@@ -44,7 +44,7 @@ Using the *logged-in users can do anything* authorization strategy can be a sens
 This is the default with Jenkins's single admin user when setting up Jenkins with the setup wizard.
 +
 Switching to an authentication realm that allows untrusted users to have an account later will result in those users getting administrative access to Jenkins if you keep this authorization strategy.
-Examples include enabling account signup for _Jenkins' own user database_, or various other authorization realms, many of which (GitHub, Google, GitLab, etc.) allow anyone to sign up for an account.
+Examples include enabling account signup for _Jenkins user database_, or various other authorization realms, many of which (GitHub, Google, GitLab, etc.) allow anyone to sign up for an account.
 
 Anonymous and authenticated users::
 Similar to the previous items, you should generally not grant significant permissions to `anonymous` (the anonymous user) or authenticated (any authenticated user) when using an authorization strategy that allows finer-grained control (like plugin:matrix-auth[Matrix Authorization Strategy]).

content/doc/book/security/managing-security.adoc

@@ -39,7 +39,7 @@ some of them.
 == Enabling Security
 
 Beginning with Jenkins 2.214 and Jenkins LTS 2.222.1, the "Enable Security" checkbox has been removed.
-Jenkins own user database is used as the default security realm.
+Jenkins user database is used as the default security realm.
 
 In versions before Jenkins 2.214 and Jenkins LTS 2.222.1, when the *Enable Security* checkbox is checked,
 users can log in with a username and password in order to
@@ -104,7 +104,7 @@ Delegate to servlet container:: For delegating authentication a servlet
 container running the Jenkins controller, such as
 link:https://www.eclipse.org/jetty/[Jetty]. If using this option, please consult
 the servlet container's authentication documentation.
-Jenkins’ own user database:: Use Jenkins's own built-in user data store for
+Jenkins user database:: Use Jenkins's own built-in user data store for
 authentication instead of delegating to an external system. This is enabled by
 default with new Jenkins 2.0 or later installations and is suitable for smaller
 environments.

content/doc/book/system-administration/admin-password-reset-instructions.adoc

@@ -30,7 +30,7 @@ You may use this command: `systemctl start jenkins`.
 After restarting Jenkins, navigate to your controller and sign in.
 7. On the dashboard, select *Manage Jenkins* in the navigation pane on the left side of the page.
 8. On the *Manage Jenkins* page, under the *Security* section, select *Configure Global Security*.
-9. Under *Security Realm*, select *Jenkins' own user database* from the dropdown menu.
+9. Under *Security Realm*, select *Jenkins user database* from the dropdown menu.
 Ensure the option *Allow users to sign up* is unchecked and save your changes.
 This redirects you to the Manage Jenkins page.
 10. On the **Manage Jenkins** page, select **Users**.

content/security/advisory/2014-02-14.adoc

@@ -33,7 +33,7 @@ Deleting the user was not invalidating the API token, allowing users to access J
 Jenkins UI was vulnerable to click jacking attacks.
 
 === SECURITY-79
-"Jenkins' own user database" was revealing the presence/absence of users when login attempts fail.
+"Jenkins user database" was revealing the presence/absence of users when login attempts fail.
 
 === SECURITY-77
 Jenkins had a cross-site scripting vulnerability in one of its cookies. If Jenkins is deployed in an environment that allows an attacker to override Jenkins cookies in victim's browser, this vulnerability can be exploited.

content/security/advisory/2015-02-27.adoc

@@ -25,7 +25,7 @@ This vulnerability allows authenticated users to disrupt the operation of Jenkin
 This vulnerability allows users with the read access to Jenkins to retrieve arbitrary XML document on the server, resulting in the exposure of sensitive information inside/outside Jenkins.
 
 === SECURITY-166 (HudsonPrivateSecurityRealm allows creation of reserved names)
-For users using "Jenkins' own user database" setting, Jenkins doesn't refuse reserved names, thus allowing privilege escalation.
+For users using "Jenkins user database" setting, Jenkins doesn't refuse reserved names, thus allowing privilege escalation.
 
 === SECURITY-167 (External entity processing in XML can reveal sensitive local files)
 This vulnerability allows attackers to create malicious XML documents and feed that into Jenkins, which causes Jenkins to retrieve arbitrary XML document on the server, resulting in the exposure of sensitive information inside/outside Jenkins.

content/security/advisory/2015-10-01.adoc

@@ -36,5 +36,5 @@ If you're running a Jenkins instance on a public network, link:https://wiki.jenk
 It is important that it is _not_ possible for anonymous users to perform administrative actions or run scripts. This means:
 
 * Do *not* use the _Anyone can do anything_ authorization strategy.
-* Do *not* use the _Logged-in users can do anything_ authorization strategy while allowing users to sign up when using _Jenkins’ own user database_.
-* Do *not* give significant permissions (beyond read access) to the _authenticated_ group when using a more complex authorization strategy such as _Matrix-based security_ while allowing users to sign up when using _Jenkins’ own user database_.
+* Do *not* use the _Logged-in users can do anything_ authorization strategy while allowing users to sign up when using _Jenkins user database_.
+* Do *not* give significant permissions (beyond read access) to the _authenticated_ group when using a more complex authorization strategy such as _Matrix-based security_ while allowing users to sign up when using _Jenkins user database_.

content/security/advisory/2018-10-10.adoc

@@ -74,7 +74,7 @@ issues:
     severity: medium
     vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
   description: |
-    By accessing a specific crafted URL on Jenkins instances using _Jenkins' own user database_, users without Overall/Read access could create ephemeral user records.
+    By accessing a specific crafted URL on Jenkins instances using _Jenkins user database_, users without Overall/Read access could create ephemeral user records.
 
     This behavior could be abused to create a large number of ephemeral user records in memory.
 
@@ -88,7 +88,7 @@ issues:
     severity: medium
     vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
   description: |
-    When signing up for a new user account on instances using _Jenkins' own user database_, Jenkins did not invalidate the existing session and create a new one.
+    When signing up for a new user account on instances using _Jenkins user database_, Jenkins did not invalidate the existing session and create a new one.
     This allowed session fixation.
 
     Jenkins now invalidates the existing session and creates a new one when logging in after user signup.