Koozali.org: home of the SME Server
Obsolete Releases => SME 7.x Contribs => Topic started by: Cylindric on March 04, 2008, 11:56:29 AM
-
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.
# 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
-
What version of smeserver-subversion are you using? Please post the output of
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 (http://bugs.contribs.org/show_bug.cgi?id=3998).
-
Oddly enough, that command produces no output (I'm currently running in an SSH terminal as root), but I can get this:
# rpm -q smeserver-subversion
smeserver-subversion-1.4-5.el4.sme
That bug looks like the same issue though, I'll try the upgrade
-
# rpm -q smeserver-subversion
smeserver-subversion-1.4-8.el4.sme
oh, and seems I was being thick :D
# 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:
<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".
-
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.
-
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: signal-event post-upgrade; signal-event rebootafter installation?
-
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
-
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)
-
[...]
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 (http://bugs.contribs.org/show_bug.cgi?id=4018) raised.