[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.
> 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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 28 17:26:56 2004