Topic: Securing smeserver-subversion for no anonymous access

[Cylindric]

Greetings folks,

Apologies if this is covered somewhere already, but I've tried searching all over but can't seem to find anything, so I'm assuming it's a shortcoming in my understanding of the general concepts that's stalling me.

I have created users Alice, Bob and Charles
I have created groups Devs (Alice & Bob) and Auditors (Charles)
I have installed the subversion contrib, and created a repo "devstuff".
The repo is "global", "auth required", "force http over SSL", "enable auto versioning" and "auto MIME"

I have set Groups (read-only access) to Auditors
I have set Groups (full access) to Devs

This enables Alice and Bob to log in, but Charles cannot.

Code: [Select]

        # Read access:
        #  User(s) : alice bob
        <Limit GET PROPFIND OPTIONS REPORT>
            order deny,allow
            deny from all
            allow from all
            Require user alice bob
            Satisfy all
        </Limit>

        # Full access:
        #  Anonymous access
        <LimitExcept GET PROPFIND OPTIONS REPORT>
            order deny,allow
            deny from all
            # Denying access:
            # Read authentication required, no anonymous write access allowed
            Satisfy all
        </LimitExcept>


If I select nobody in the "read only" access, then anyone can drive-by read code, but only devs can commit.  As soon as I put someone in the read-only section, it _only_ becomes read-only.

What I want is to have nobody able to just wander past and pull documents from my SVN, currently http://mydomain/devstuff and see everything in it.

Ideally I need to to be:
anonymous: no access
auditors: read-only
devs: full-access

But I can live with
anonymous: no access
devs: full-access

Hope I'm being clear, and aren't just missing something obvious.

Thanks

[cactus]

What version of smeserver-subversion are you using? Please post the output of

Code: [Select]

db accounts show reponame
There are a hand-full of bugs reported with the latest release and I am working on fixing the issues. This one might be the one you are hit by: http://bugs.contribs.org/show_bug.cgi?id=3998.

[Cylindric]

Oddly enough, that command produces no output (I'm currently running in an SSH terminal as root), but I can get this:

Code: [Select]

# rpm -q smeserver-subversion
smeserver-subversion-1.4-5.el4.sme
That bug looks like the same issue though, I'll try the upgrade

[Cylindric]

Code: [Select]

# rpm -q smeserver-subversion
smeserver-subversion-1.4-8.el4.sme
oh, and seems I was being thick

Code: [Select]

# db accounts show name_of_my_svn_repo
name_of_my_svn_repo=repository
    AccessType=global
    AuthentificationRequired=yes
    Description=MyRepo
    ForceSSL=yes
    GroupsRead=auditors
    GroupsWrite=devs
    ModMimeUseProfilePath=on
    Modifiable=yes
    Removable=yes
    SVNAutoVersioning=on
    UsersRead=
    UsersWrite=

#db accounts show devs
devs=group
    Description=Developers
    Gid=5008
    Members=alice,bob
    Uid=5008

#db accounts show auditors
auditors=group
    Description=Auditors
    Gid=5001
    Members=charles
    Uid=5001


And the httpd.conf section:

Code: [Select]

    <Location /name_of_my_svn_repo>
        DAV svn
        SVNPath /home/e-smith/files/repositories/name_of_my_svn_repo
        SVNAutoVersioning on
        ModMimeUsePathInfo off
        AuthName "MyRepo"
        AuthType Basic
        AuthExternal pwauth

        # Read access:
        #  User(s) : charles
        <Limit GET PROPFIND OPTIONS REPORT>
            order deny,allow
            deny from all
            allow from all
            Require user charles
            Satisfy all
        </Limit>

        # Full access:
        #  User(s) : alice bob
        <LimitExcept GET PROPFIND OPTIONS REPORT>
            order deny,allow
            deny from all
            allow from all
            Require user alice bob
            Satisfy all
        </LimitExcept>
    </Location>

It now correctly forces me to enter a username/password to see the repo, and accepts the r/o credentials, but doesn't accept the r/w credentials.

One of the problems seems to be that selecting nothing in the "read-only" box seems to imply "let anyone in" and not "let nobody in".

[cactus]

One of the problems seems to be that selecting nothing in the "read-only" box seems to imply "let anyone in" and not "let nobody in".

Yes that is a design choice as I see no harm in read-only access fro everyone in my situations, if you see otherwise please raise a bug and I will see if I can implement it, although I do not need it.

[cactus]

It now correctly forces me to enter a username/password to see the repo, and accepts the r/o credentials, but doesn't accept the r/w credentials.

Please report issues, including proof and all relevant configuration details, in the bugtracker as it is much easier for me to track it there than in the forums. Did you follow all instructions to the letter including:

Code: [Select]

signal-event post-upgrade; signal-event rebootafter installation?

[Cylindric]

Yes that is a design choice as I see no harm in read-only access fro everyone in my situations, if you see otherwise please raise a bug and I will see if I can implement it, although I do not need it.

No, I can see both angles and I guess both are valid If "none-selected" means "open" that's fine, as long as I can create a group perhaps called "dummygroupnoaccess" and put that into the "readonly" box, and then have the "developers" group in the "full access" box.

I've just registered for the bugzilla, so I'll post details in there as relevent, I just didn't want to polute it too much with user-error

Thanks for the prompt responses,

Mark

[Cylindric]

Aha!  That seems to be working as intended with the new version now \o/

I just had to learn a bit about the whole <limit> and <limitexcept> stuff to get my head around it.

Basically, it's because I was assuming that "full-access" meant full-access, but what it seems to mean is more like "add write-access", so you still need read access.  "Read-only" is not only read-access, ie it doesn't "block" full access.  You need that one too!

So now my groups are:

Developers: Alice, Bob
Auditors: Alice, Bob, Charles

Groups (read-only access): Developers, Auditors
Groups (full access): Developers

Resulting in an httpd with:
Limit: Require user alice bob charles
LimitExcept: Require user alice bob

Perhaps the labels could be changed slightly to help numpties like me?  (I'm not all that familiar with SVN, so if these map onto existing conventions then I guess it's just my fault)

That's not a bug though, the last update fixed the actual problem   Perhaps once I've got access to the Wiki I'll make a note on there.  (Still not read the faq's on that, so been keeping clear of it so far)

[cactus]

[...]

Basically, it's because I was assuming that "full-access" meant full-access, but what it seems to mean is more like "add write-access", so you still need read access.  "Read-only" is not only read-access, ie it doesn't "block" full access.  You need that one too!

[...]

Perhaps the labels could be changed slightly to help numpties like me?  (I'm not all that familiar with SVN, so if these map onto existing conventions then I guess it's just my fault)

Thanks for the suggestion.

That's not a bug though, the last update fixed the actual problem   Perhaps once I've got access to the Wiki I'll make a note on there.  (Still not read the faq's on that, so been keeping clear of it so far)

Even a suggestion/new feature request should be a bug: bug 4018 raised.