non administrative users can modify permissions

Issue #90 invalid
created an issue

I noticed that users who don't have administrative or ownership rights can modify permissions for a repository. This should not be allowed. In fact this is a security breach. I would love to know your thoughts, and possible ways to circumvent this problem.

Comments (39)

  1. srsarangi reporter

    (Reply via

    hi, I logged into a student's system and did some changes to the repository. Then the student logged into the webpage without closing the browser window. She was able to see all the repositories, including those that she didn't have permission to see. She was also able to change permissions for all users.

    A trivial solution to this problem is to force users to shut down their browser window, after logging out. You can also think about clearing off cookies, or deleting some kind of local session state.

    My two cents --Smruti Sarangi ----------------------------------------------------------------- Smruti Ranjan Sarangi Assistant Professor Computer Science and Engineering Bharti Building, Block IIA IIT Delhi, Hauz Khas, New Delhi-16 Ph: +91 11 2659 7065, +91 9650622884 Website: ------------------------------------------------------------------

  2. Anonymous

    I just encountered the very same problem.

    Steps to reproduce:

    1. Login as administrator
    2. Log out
    3. Login as non-admin
    4. Click on any repository (Subversion) in the list
    5. Click on the permissions tab at the bottom
    6. Edit permissions as desired ;-)

    My deployment is basically a default installation with the following exceptions:

    1. Non-SSL access is disabled
    2. SSL access is enabled
    3. The LDAP plugin is configured

    Especially the LDAP plugin may be a noteworthy deviation from the default as all users in question originate from the LDAP server.

  3. Sebastian Sdorra repo owner

    Could you post the log lines from a wrong authentication? With enabled trace logging?

    Enable trace logging:

    Edit scm-server/conf/logging.xml Change the line from:

    <logger name="sonia.scm" level="INFO" />


    <logger name="sonia.scm" level="TRACE" />
  4. DoctorRockit

    I just enabled the increased logging verbosity and restarted the server and since then I can't reproduce the observed behavior, even though the condition was permanent before the restart.

    At first I tried it with the unprivileged user, with whom I could reproduce the error the first time, then I also tried it with a new unprivileged user loaded from the LDAP directory, who was previously unknown to SCM Server. In neither case I was able to reproduce the observed behavior.

    I will add more information to this report when I'm able to reproduce the error.

  5. DoctorRockit

    I observed something different, prior to the restart and was about to file a separate issue for this, but since this condition is also gone after the restart, I'll add it here as supplemental information that might help track down the problem:

    While the abovementioned condition persisted authorization/permission checking on repositories managed by SCM Server did not work either. All authenticated users had read/write privileges to all repositories, regardless of the permissions set on the individual repositories.

  6. DoctorRockit

    The users were ordinary users, who were not even known to SCM Manager prior to the first (SVN) checkout. This appears to match the observed behavior of the Web-Frontend mentioned in the initial report, where all users were considered admins with respect to the (erroneous) permission to edit (all) repository details and permissions.

  7. DoctorRockit

    I will post details once I'm able to reproduce both behaviors. But since the error is currently gone (after the restart) I can't give you a precise estimate of when I will have the information.

  8. Sven Ginka

    This behavior is totally reproduceable. I used the same browser for both logins.

    And yes it seems to be a caching problem. Because I cleared the browser cache and everything went fine !!! Probably some access information are stored in the browser cache. As you can see the menu items are hidden. However some priveleges like setting permissions are still available.

    What can we do here?



  9. Sven Ginka

    Now after clearing my browser cache I can not create the situation where my browser cached the user/admin data. I am concerned not knowing what created this special situation.

  10. Sebastian Sdorra repo owner

    The problem is the local browser cache and the error could only occur on the same machine with the same browser instance.

    SCM-Manager uses the Last-Modified and the E-Tag header for local caches. The E-Tag is generated from the list of repositories which changes when the permission are changed. I think the problem is the Last-Modified header which is taken from the database. The Last-Modified header changes only if a repository is created, deleted or modified. Could you check this behavior with firebug or chrome developer tools?

  11. Sven Ginka

    I got it!

    I logged in as admin. Strangely I had to login twice: one the usual login window and second there appeared a standard login window (like the apache login windows) after the second login window disappeared my browser asked me to store the login information. I hit yes.

    Now logging in as user makes the user to super-user!

  12. Sven Ginka

    1. ) the second login windows is not always present. just from time to time.

    2. ) Yes, I did remove the anonymous user

    What is the anonymous account for?

  13. Sebastian Sdorra repo owner

    I think the complete problem is related to the mix from authentication via ui and the basic authentication from the browser. When you login with the basic authentication (e.g. access a repository directly), then the browser stores this information until you close the browser (or you clear the cache and authentication informations). So if you loggedin via basic authentication and logout with the normal logout link in the interface, your browser will use the basic authentication for every ajax call regardless of the logout. But i'm not able to disable the basic authentication, because this authentication is used from the repository clients (svn, hg and mercurial). As far as i know it is not possible to logout a basic authentication without use of ugly hacks.

    The anonymous user is for the "Allow Anonymous Access" function. In the next release i will deny deletion of the anonymous user.

  14. Sebastian Sdorra repo owner

    Ok, i was able to reproduce this problem. But it is not a failure from scm-manager. It is the normal behavior of each browser. I will try to describe the problem.

    • Open a url of a repository, login as admin with basic authentication
    • Goto the normal user interface, you will automatically logged in as admin. Because of the session started with the basic authentication
    • logout and login as normal user
    • Go back to the repository url, now comes the problem: the browser will send the basic authentication of the admin automatically again. A new session as admin is started.
    • When you now go back to the user interface and press the refresh button for repositories, you will see the repositories of the admin account. Because the admin session from the automatically basic authentication is active. If you reload the complete page you will see the name of the admin account in the right corner.

    I'm not really sure, but i think the problem could not be fixed. Because the browser will send the basic authentication until the browser is closed. This problem occurs only on the same machine, with the same browser and if the browser is not closed during the steps above. I think i can mark the issue as invalid, because the behavior is normal for each browser and occurs in every application that must mix basic authentication and form based.

  15. Sven Ginka

    Its great you understand the problem and also can reproduce it. However I can not follow you because I did not review the sources of SCM yet.

    Let me try to understand the situation. From my point of view the authentication mechanisms are different. HG-Web is using standard browser auth. storing passwords and co in the browser and SCM is using a different authentication method (probably storing auth. settings in cookies). It is hard to understand why they should interfere.

  16. Sebastian Sdorra repo owner

    I have to use the basic authentication for the repositories, because of the repository clients (hg, svn and git) they accept only basic authentication. But i could not use basic authentication for the user interface, because this would break the "Allow Anonymous Access" function and basic auth for normal web applications is ugly in my opinion.

  17. Sven Ginka

    So the over-all solution is:

    If anyone experiences this situation : clear the browser cache and everything is fine.

    I can live with that.



  18. Sebastian Sdorra repo owner

    Just for clarification, you do not have to clear the cache. You have just to close the browser and only if you used the basic authentication and only if an other user will work on your machine with the same browser.

  19. Log in to comment