[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2

From: Paul Oppenheim <poppenhe_at_umich.edu>
Date: 2004-05-27 05:09:04 CEST

i have a few things to add, plus i figured everyone would want to see
this :)

On May 26, 2004, at 10:40 PM, Greg Hudson wrote:

> [Apologies to those people in this conversation who aren't Paul, and
> aren't seeing my messages. I'm subscribed to this list via a
> different account, and I don't seem to be getting along with the list
> moderation software.]
>> the daemon checks to see if that user has permission (in the users
>> file? in the repository's group? in the crystal ball?), but then
>> acts on the DB as the user that started the daemon.
> That's authorization, not authentication.

my bad :)

they say the internet makes us dumber...

>> a daemon authenticates a local user already if you
>> svn://localhost/...
> Only if you give it a password database and specify a password, which
> would seem superfluous if you've already authenticated via ssh.
> There's no simple, portable localhost-only IPC facility in Unix which
> securely communicates the uid from one side to the other. The closest
> you can get is setuid/setgid, and going that path introduces new
> potential for security holes. So, this isn't really a good path to
> making svn+ssh work out of the box.

I agree.

however, right now my problem is that i need something to observe
groups (maybe just a list of system usernames). I know that's what the
UNIX groups system is supposed to do, but the umask problem (BDB
problem?) is making them moot, so is there needed to be a single daemon
accessing the DB, then maybe I could give it a list of local user
accounts / UIDs so that it could determine access that way.

Then (after i sent the messages) i realized yeah, ports and socket
connections are really the only IPC communication method that works,
and those ports are for everyone to talk to. I guess a firewall's the
only thing that would make this smiley. I don't think that would make
many happy :)

> In a different message, Paul wrote:
>> But in the end I was hoping for an answer like: "well, nobody
>> thought that the file:// method would bork the repository, and now
>> we have to wait for the fix." not "there's no magic way to make it
>> work out of the box."
> svn+ssh is really only one facet of the problem. I've seen people
> experience the problem mixing daemon-mode svnserve with viewcvs
> running under a different uid, for instance.
> As much as it affects many users today, the umask/permissions problem
> is not a sufficient reason to torque the entire design of svn+ssh so
> that it requires a persistent daemon to be running on the server
> machine and requires us to solve the transparent localhost
> authentication problem.

I think you're right, because of the IPC problem. That's a little out
of the svn domain :)

i guess the solution is fixing local access; many users _must_ be able
to sanely use one DB. To be honest, that's a pretty reasonable
expectation from a DB, regardless of umask.

so... i guess if anyone on here works on BDB... :)

- paul

i just wanted to start developing this game, and then....

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 27 05:09:55 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.