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