My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 351: Gerrit reports a project doesn't exist when a user doesn't have correct permissions
14 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Owner:  ----
Closed:  Mar 2013


Sign in to add a comment
 
Reported by nick.mu...@gmail.com, Dec 8, 2009
Affected Version: 2.0.23
Environment: Ubuntu 8.04.3, Jetty 6.1.14, Java 1.6.0_12, PostgreSQL 8.3.7

What steps will reproduce the problem?
1. Log into Gerrit
2. Copy ssh key into Gerrit
3. Attempt a "repo init"

What is the expected output? What do you see instead?

A new user was trying to perform a "repo init" for the first time on his
workstation and saw the following output:

$ repo init -u ssh://bar.foo.com:29418/foo-bar/platform/manifest -b dev
--repo-url=git+ssh://bar.foo.com:29418/foo-android/tools/repo.git
--no-repo-verify
Getting repo ...
from git+ssh://bar.foo.com:29418/foo-android/tools/repo.git
fatal: '/foo-android/tools/repo.git': not a Gerrit project
fatal: The remote end hung up unexpectedly

Originally, I had expected the "repo init" to work correctly.  I later
discovered that the user was not a member of previously established LDAP
groups with read permissions in Gerrit.  That being the case, I would have
expected to see a "permission denied" type message, not a message stating
that the requested project did not exist, when in fact it did.

This behavior could be confusing and might lead some down the wrong path
when troubleshooting, as it gives no overt indication that it is a
permissions problem.

-Nick
Dec 9, 2009
#1 sop@google.com
Actually, this was a conscious design decision.

git-daemon returns the same ambiguous error status when the daemon isn't 
permitted to read a repository or the repository doesn't exist.  This prevents a 
remote attacker from probing the project namespace to determine if something is 
hosted here, or not.

That said, I can see in certain installations where its OK to leak project names via a 
probing attack, because users who can access the system are already otherwise 
restricted to a relatively trusted subset, e.g. a corporate firewall only allows 
employees to contact the server, or an LDAP directory was configured to only allow 
users with active LDAP accounts to login to Gerrit.  Or the installation is meant to be 
completely open and an access error is a misconfiguration the administrator wants to 
identify and resolve.

So we should actually make this a configurable option, and default to two different 
error messages:

* "project not found"  == name really is not in database
* "access denied" == name is correct, user lacks READ +1

Status: Accepted
Dec 9, 2009
#2 nick.mu...@gmail.com
Shawn,

I can definitely understand the design decision and the security implications.  The
thought that it was a security decision did cross my mind.  I agree with the
configurable options you mentioned.  Thanks for your help!

-Nick
Aug 31, 2011
Project Member #3 edwin.ke...@gmail.com
Well, this new configuration option is still not implemented, but at least the error message is documented by now [1] so that users can conclude that they are actually missing read access for the project.

[1] https://review.source.android.com/Documentation/error-not-a-gerrit-project.html
Mar 28, 2013
#4 sop@google.com
(No comment was entered for this change.)
Status: WontFix
Jan 2, 2015
#5 ramidi.m...@gmail.com
Nice post really help full for starters
Sign in to add a comment

Powered by Google Project Hosting