Closed Bug 454510 Opened 17 years ago Closed 16 years ago

Provide way to check if a user has SVN permissions

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
All
Other
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: clouserw, Assigned: aravind)

Details

When a user has an LDAP account but doesn't have SVN permissions to a directory it's harder to handle via a web app because we have to store their changes, tell them they don't have permission (as opposed to another SVN error) and ask them to take the time to fix it - when all they wanted to do was commit something. It would be a better user experience if the user could log in to the web app, attempt to edit something and be told before hand that they don't have permission and they'll need it before they can commit. To do this webdev needs a way of seeing who has permissions to what directories. Perhaps this can be an LDAP attribute?
svn does this with a flat file in the top-level config directory, and it's based on a combination of groups and pathnames and so forth. If you can come up with a way to parse that file we can probably rsync it somewhere you can get at on a regular basis or something. (or if you get something that can parse it that can be queried, we can probably put it on the server and let you hit it there to query it)
Sorry, meant to paste this in here, too: http://svnbook.red-bean.com/en/1.4/svn.serverconfig.pathbasedauthz.html (docs for said file format)
Dave - is this public information? If someone has access to a directory or not? I could probably whip up some sort of web service page really quickly that would let you do, say: check_svn_access.php?path=/foo/bar&user=foo@bar.org And it would return either 'rw', 'ro', or 'undefined'. (Of course, that makes me wonder, do we have directories in SVN that are private? Or is everything by default readable? I believe that's the case...)
Assignee: server-ops → mark
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Dave? :)
I'm not sure there's anything confidential about who can see what, though it might help a cracker figure out which account he needs to hack to get privs I suppose. That's probably more of an aravind question since he set all that up.
Wil: Is comment #3 as a solution acceptable to you?
> Is comment #3 as a solution acceptable to you? I think it sounds great
Wil: Okay, this is all setup. All I need now is a list of paths you're going to be checking so I can whitelist them in the script. (We're not going to expose all paths, only the ones that you care about, to try to maintain some security on the access list.) So yeah, just a list to the svn paths you care about, and I'll have this for you ready to use tomorrow...
Umm, all the paths that localizers have access to in the config file? I think there is a localizers group with access to several paths, right? Some example paths that would be in there would be: /vc/projects/mozilla.com/trunk/* /addons/trunk/site/app/locale/* /projects/mozilla-europe.org/trunk/* In fact, that might be all the paths. Since there is a whitelist can you differentiate the return values for these conditions: - path doesn't exist in whitelist - user has permission - user does not have permission - something else went wrong; page xb95 asap <3 Thanks!
Three paths added, and responses from the script should indicate in a pretty straightforward fashion what the user can and can't do. I'll document and move it to a more permanent home tomorrow (or try, kick me if I fail) and we'll keep this ball rolling.
We're going to be moving this to the svn/hg frontend servers. I'm working with Aravind to ensure proper setup and security of the script.
Assignee: mark → aravind
I can't find this check_svn_access.php script. Does anyone know where Mark was developing it?
it's at people.mozilla.org:/var/www/cgi-bin/svn-acl/
I would like to move our svn root from svn.m.o to svn.m.o/svn. Should have done this a long time back. If we don't, we'd have to put in all kinds of work-around to get around that. This doesn't prevent me from giving you the check at a different url, but this is a good thing to do anyway. The first impact you will notice is svn operations will fail with this message. svn: Repository moved temporarily to 'http://svn.mozilla.org/svn/projects/mozilla.com/branches/cms_testing'; please relocate Is this acceptable. I will look into what it takes to fix viewvc so we keep all the history intact through the move. If you guys think this move will be way too disruptive, I can simply provide this check at a different url like svnperms.m.o/check.cgi or something like that. In general though, moving the root from / to /svn is the right thing to do moving forward.
(In reply to comment #14) > If you guys think this move will be way too disruptive, I can simply provide > this check at a different url like svnperms.m.o/check.cgi or something like > that. I definitely think this would be a huge disruption. I don't think it's worth it at all. > In general though, moving the root from / to /svn is the right thing to > do moving forward. Why do you think that? Are subdomains really such problems? Why not <something>.svn.mozilla.org like ViewVC has?
The main problem with leaving our svn root at / is that it makes it virtually impossible to add any kind of url filtering or re-direction. This is probably also the reason that the svn docs recommend hosting the repos at something other than /. For just this script, we can do a subdomain (its not all that different from doing a completely new domain).
(In reply to comment #15) > (In reply to comment #14) > > If you guys think this move will be way too disruptive, I can simply provide > > this check at a different url like svnperms.m.o/check.cgi or something like > > that. > > I definitely think this would be a huge disruption. I don't think it's worth it > at all. Agreed, I'd vote for a subdomain over moving the root.
Please use http://vcperms.mozilla.org/cgi-bin/svn_perms.cgi with the arguments Mark listed earlier.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.