[#720] SCM rights for global groups are not validated in plugin scmsvn



Detailed description

One of our users stumpled upon this today. The following applies to the plugin scmsvn. I don't know if the same applies to other scm plugins. Since FusionForge 5.1 and the role-based access control system there are the global groups "Anonymous/not logged in" and "Any user logged in".

If you set read permission in SCM for the global group "Any user logged in", then nothing will change in the access file. From an user point of view "* = r" should be added. The same happens if you set write permissions. There should be "* = rw", but nothing is added to the access file.

If you set write permissions for the group "Anonymous/not logged in" in SCM, then the user anonsvn and every authenticated user is added with read permissions.

After a quick look in the code from 5.2.2, 5.2.4 and 5.3.1 I assume the behaviour is still the same from before 5.1 with the flag enable_anonscm in the table groups where everone authenticated and the anonsvn user was added with read permissions.

Code from the SVN plugin:

if ($project->enableAnonSCM()) { $accessdata .= forgegetconfig('anonsvnlogin', 'scmsvn')." = r\n"; $access_data .= "* = r\n"; }

$project->enableAnonSCM() does only check if the global role "Anonymous/not logged in" has read permissions. If the read permissions are there, then every authenticated user and the anonsvn login get read access to the repository.

General Information
Submitted by:
Markus Köhl
Date Submitted: 2014-09-01 11:32
Last Modified by: Nobody
Last Modified: 2017-11-02 20:00
Date Closed: 2015-05-22 13:26
Permalink: https://fusionforge.org/tracker/a_follow.php/720
Votes: 0/1 (0%)
Internal Fields
Data Type: Bugs
Assigned to: Nobody (None)
State: Closed
Priority: 3
Extra Fields
Target Release:
Found in Version:
Follow-up tabs
Message  ↓
Date: 2015-05-22 13:26
Sender: Sylvain Beucler

This part of privileges handling was rewritten in 6.0.

Date: 2014-09-10 08:03
Sender: Franck Villaume

One remark, the role "Any Logged In" assume you have a valid fusionforge cookie, that you are actually logged on the FusionForge website. This role does apply only to the FusionForge website.

Giving SCM read or write access to this role is a little bit odd since you can have access to SCM repo without being logged in.

Not sure digging more into this make sense.

Still here is my point of view on your proposal. Option 1: Creating a group is a nice idea and should probably extended to any role. Option 2: not sure this is going to make a simple solution... I like to KISS.

Date: 2014-09-09 15:32
Sender: Markus Köhl


for the third element:

Option 1 would be the easiest, but I think adding exceptions for just this role would just make it more complicated in the future. Option 2 would be the most accurate, but I also understand your security concerns about private projects and the potential to create a ressource pig out of the php cronjob createscmrepos.php.

But I don't think both options will be accurate. Please correct me if I'm wrong or missing something.

  • public/private projects A private project is a project with no linked roles "Anonymous/not logged in" and/or "Any logged In", or the project visibility option set to hidden for both roles. If a project administrator decides to add one of these roles and sets the project visibility or any other access right to something other than "Hidden", or "no access" the project is not private anymore by definition.

  • Authentication / Authorisation There are several ways (the auth* plugins) to authenticate in a FusionForge system, but you have to configure every plugin in it's own way to match your environment. Regardless of what plugin you choose, you are authenticated within the FusionForge PHP framework. In case of authldap the credentials of the user in the FusionForge database will also be updated if they don't match with the given credentials.

For the location /svn authentication is done by only by apache httpd. In the file ./etc/httpd.conf.d/plugin-scmsvn.inc there is the setting "AuthUserFile {core/data_path}/svnroot-authfile". So every user in the forge, that gets SVN access in at least one project has to be added to the svnroot-authfile. In case an user does not have access to a project using svn, the user will not be added to the svnroot-access-file at the moment.

After authentication comes authorisation. There is the setting "AuthzSVNAccessFile {core/data_path}/svnroot-access" which points out which user has access to which repository (or path, if you use only one).

I don't think there is a very clean solution for this, but after thinking about this over the weekend, I'd like to add two options:

<Option 1>

The access file also allows definition of groups. So instead of adding every user of the forge in every repository, there is also the possibility to add an entry like this:

[groups] PFO_RoleLoggedIn = <Every user in the forge>

and add the group to the repos entry

[test:/] @PFO_RoleLoggedIn = r

See: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html

This would decrease the possible size of the svnroot-access file in large forges, but every user still has to be added to the svnroot-authfile.

<Option 2>

(This is just an idea and still requires extensive thinking) The apache configuration could be modified to include the configuration for other AuthBasicProviders like ldap which are also used in the forge. Authentication will be the same as in the forge, but the user does not have to exist in the svnroot-authfile.

Date: 2014-09-06 15:56
Sender: Franck Villaume

another remark: in case of ssh access, it's obvious that anonymous access wont work since there is no anonymous user...

Date: 2014-09-06 15:52
Sender: Franck Villaume

woups missing commit id: b1f2fa6276880e817b700470a577ce9a02017e39

Date: 2014-09-06 15:49
Sender: Franck Villaume

anonymous permission setting fix. Branch53 commit:

Date: 2014-09-06 11:01
Sender: Franck Villaume


there are some bugs or explanations needed here.

First element: anonymous access. The level of permission is not taken into account. That means even if you set write access, you will have read access. This need to be fixed.

Second element: the "* = r" in svnroot-access file for anonymous access. The httpd configuration says to access svn repo you require a valid user. This line is probably useless due to httpd configuration.

Third element: the "Any logged In" role. When we compute the users list to be add in the svnroot-access and svnroot-authfile, we look at every role linked to the project and we search for users with this role. In case of "Any logged In" role, there is no users with this role. So we add no users to the files. "Any logged In" does not mean : "any user declared in the forge" but any user with an active session. 2 options here : 1) we stay the way we deal with this role and fix the permission level the role can have. Actually : no access, read, write. New levels would be : "no access, online forge read" 2) when we compute the role / users, the global "Any logged In" role returns the complete list of active users and we add all users to svnroot-authfile and svnroot-access files.

The second option shows some limitations : 1) In case of 16k users forge (such as http://gforge.inria.fr/) we will generate a gigantic svnroot-authfile & svnroot-access files 2) the php script will probably be a ressource pig. 3) we cannot use "* = r" or "* = rw" in any case. It's a security breach for private projects.

For both first and second element, we can make a fix. For the third element, what is your opinion? The second option does not sound like a reasonable approach.

Date: 2014-09-05 15:27
Sender: Markus Köhl


lets try a simple example. There is project "test" using SVN as SCM system with the roles "Developer" and "Reader". The global roles "Any user logged in" and "Anonymous/not logged in" are also linked to the project.

The SCM access rights for the roles are set to the following: Developer = write Reader = read "Any user logged in" = read "Anonymous/not logged in" = write

There are three users in the project. Developer and Reader. Every user is mapped to the group with the same name.

From a logical point of view the access file should look like this for the project: [test:/] Developer = rw Reader = r anonsvn = rw * = r

Instead it looks like this: [test:/] Developer = rw Reader = r anonsvn = r * = r

If you unlink the global role "Anonymous/not logged in" from the project it will look like this: [test:/] Developer = rw Reader = r

Like I tried to describe in the bug description, the implementation of the plugin still uses the private/public projects behaviour like in before 5.2. As far as I know this is deprecated and was replaced with the RBAC implementation, but for this case it was only partially done.

Date: 2014-09-05 13:35
Sender: Franck Villaume

Hi, thank you for reporting.

I need some information to be sure to understand your bug. You added "Any logged In" global role to your project, you set scm read / write access to the global role. Yet, the svn access file does not contain any new line. Am I right? In case you add "Any logged In" global role and set read access to scm, do you expect to get a line like : "* = r" in the forge in svnroot-access file and a line per user available in the forge in the svnroot-authfile?

What happen if the project is private (no anonymous access) but another project is public ? does the anonymous user access to the private scm repo?

No attached documents

No related commits.

Field Old Value Date By
status_idOpen2015-05-22 13:26
Sylvain Beucler
close_dateNone2015-05-22 13:26
Sylvain Beucler
Target Release5.3.32015-05-22 13:26
Sylvain Beucler
ResolutionAccepted As Bug2015-05-22 13:26
Sylvain Beucler
Target Release5.3.22014-09-19 12:02
Franck Villaume
Target ReleaseNone2014-09-06 15:49
Franck Villaume
SeverityNone2014-09-06 15:49
Franck Villaume
ResolutionNone2014-09-06 15:49
Franck Villaume

No relations found.