Repository navigation
[JENKINS-18884] Seperate Permission for People View to close Security Hole with AD Plugin #14767
Description
Even when choosing the most restricted user rights (Role Plugin: Global Role only 1 Read), it is possible for every user to view the Jenkins User Id AND the name of the user (see screenshots).
Working with an Active Directory for authentication, this means its possible for everybody to get the user names from AD AND the common names (Security Hole with AD Plugin?).
Goal: create a Permission to allow specific People/Roles to see this User Account info and deny it to all others.
Originally reported by night_shift, imported from: Seperate Permission for People View to close Security Hole with AD Plugin
- assignee:
danielbeck
- status: Closed
- priority: Major
- component(s): core
- label(s): configuration, permissions, security, security-hardening
- resolution: Fixed
- resolved: 2024-04-02T14:43:59+00:00
- votes: 21
- watchers: 29
- imported: 2025-11-24
Raw content of original issue
Even when choosing the most restricted user rights (Role Plugin: Global Role only 1 Read), it is possible for every user to view the Jenkins User Id AND the name of the user (see screenshots). Working with an Active Directory for authentication, this means its possible for everybody to get the user names from AD AND the common names (Security Hole with AD Plugin?).
Goal: create a Permission to allow specific People/Roles to see this User Account info and deny it to all others.
environment
CentOS<br/>
Jenkins
Activity
jenkins-infra-bot commentedon Nov 29, 2013
Raw content of original comment:
Without permission to view people, other views that can also be used to list people known to Jenkins should be restricted as well, like 'Changes' (remove author information?).
Maybe even information such as the field about who created a slave? Who started a build?
There's little there can be done for change lists sent via email-ext though. Other plugins might also provide ways to circumvent restrictions.
jenkins-infra-bot commentedon Nov 29, 2013
ikedam:
Raw content of original comment:
@danielbeck
I'm afraid you completely misunderstand this issue.
1. The severity is completely different that all users in Jenkins are visible and that some of users in a project is visible.
2. Changelogs can be restrict to open only to users related to that project by using Matrix Authorization Strategy Plugin. This issue is that there is no way to restrict access to "People" view.
3. Even though there are other security issues in Jenkins, it cannot be a reason to leave this issue.
4. Even though there are plugins with security issues, it cannot be a reason for Jenkins not to care security.
It is not reasonable to force users change their existing security policy only in order to introduce Jenkins.
Of course, other problems you pointed should not be left.
They should be considered to fix if someone cannot stand with them.
jenkins-infra-bot commentedon Jan 13, 2014
ikedam:
Raw content of original comment:
Notes for customization:
jenkins-infra-bot commentedon Jan 13, 2014
Raw content of original comment:
Possible workaround: Hide Jenkins behind a reverse proxy (e.g. Apache). Configure it to listen only on the 127.0.0.1 interface (--httpListenAddress=127.0.0.1). Forbid access to people/asynchPeople URLs. Those links will then result in 403 Forbidden.
Sample Apache httpd.conf excerpt, assuming reverse proxy and Jenkins are running on the same host, Jenkins on port 8080, Apache on port 80:
Of course, this simple pattern will prohibit access to e.g. the job named 'people' as well. Haven't tested this with all possible Jenkins URLs, making sure it works for those is left as an exercise to the reader
This should keep at least most of the users out, even if it's likely not a 100% solution.
jenkins-infra-bot commentedon Jan 18, 2014
ikedam:
Raw content of original comment:
Send a pull request.
#1094
Not created a new permission, but added configuration that People page requires READ permission or ADMINISTER permission.
jenkins-infra-bot commentedon Jan 26, 2014
ikedam:
Raw content of original comment:
Another approach.
#1094
From the beginning, People page does not need to list ALL users in Jenkins, does it?
jenkins-infra-bot commentedon Oct 21, 2014
Raw content of original comment:
This is a serious security breach - so - not understand why this defect is fixing so long time.
jenkins-infra-bot commentedon Jun 27, 2017
vixen03:
Raw content of original comment:
This issue is really blocking us from switching to Jenkins. Is there any forecast when this could be fixed?
jenkins-infra-bot commentedon Jul 7, 2017
Raw content of original comment:
Is out there any way to disable "people" link on the Jenkins Dashboard page ?
jenkins-infra-bot commentedon Mar 16, 2020
vladimir81:
Raw content of original comment:
Created at 2013-07-23 10:03 Are you serious? What is the chance this security hole will be resolved this month?
jenkins-infra-bot commentedon Mar 16, 2020
Raw content of original comment:
vladimir81
Please consider me as messenger here. First of all, if this is a security issue from your point of view, please report it according to https://jenkins.io/security/#reporting-vulnerabilities .It is currently considered as a Security Hardening by the Jenkins security team (see the labels). Read as "request for enhancement". If you have additional data which may alter this decision, please report it to the security team.
Everybody is also welcome to take over #1102 from ikedam and to get it over the line.
P.S: Personally I would love to see this fix integrated, and I consider it as important change to do. I am happy to help with reviews and with getting this change delivered, but I do not plan to work on this issue on my own.
jenkins-infra-bot commentedon Mar 17, 2024
minfrin:
Raw content of original comment:
Exposing users like this violates various laws in some countries. A number of PRs have been submitted to fix this, but they keep getting closed.
Who is responsible for jenkins security who can pick this up?
jenkins-infra-bot commentedon Mar 19, 2024
Raw content of original comment:
Could you link to those PRs? There are only two I'm aware of, from 2014, by the same author, and closed by their author when they lost interest, both linked above.
The Jenkins security team has no particular interest in this issue. We do not consider it to be a vulnerability. The current behavior is documented and access can be prevented by not granting Overall/Read permission. So while it may be inconvenient for your use case, it essentially "just" raises the bar who gets to have that permission in any particular organization.
jenkins-infra-bot commentedon Mar 22, 2024
Raw content of original comment:
I create a new PR: #9052, still struggeling with the tests
jenkins-infra-bot commentedon Apr 2, 2024
Raw content of original comment:
While not specifically what was requested here, 2.452 removes the People views from core. Therefore I'm closing this issue.
Install https://plugins.jenkins.io/people-view/ to restore the feature if you need it. Unlike most features moved from core into a plugin, it's not bundled or an implicit dependency from other plugins. Note that it does not require additional permissions. It's intentionally the same feature as before, just provided through a plugin.
Other plugins may implement other views on the same or similar data, possibly protected by a new permission.
jenkins-infra-bot commentedon Apr 2, 2024
fredg:
Raw content of original comment:
Thanks, Daniel, for removing the People views from core. This is a much anticipated and appreciated change!
Fingers crossed that it will be part of the next LTS baseline!
jenkins-infra-bot commentedon Nov 24, 2025
[Original
depends_onfrom Jira: JENKINS-26469]