You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Paul Oppenheim <po...@umich.edu> on 2004/05/26 15:17:45 UTC
Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Hello SVN'ers,
I'm having a problem with an SVN 1.0.2 repository that is living on a
FreeBSD 5.2 server. My team's repository is administered by a user
named 'svn' and has a group of 'Proto2004'. Two users that are also in
group 'Proto2004' are 'poppenhe' and 'woodardj'. When user 'poppenhe'
makes a commmit, user 'woodardj' cannot then use the repository.
I've examined the repository, and the problem seems to be a permissions
problem. The only time the permissions were manually modified was when
the repository was created. After creation, I did a 'chown -RP
svn:Proto2004 haquery/' to make the repository accessible to the users
of the group. Is that incorrect? The access method is restricted to
svn+ssh.
following are the current permissions of db/ -- i did none of this by
hand, except what I mentioned above. That is, these permissions are set
by svn.
[vcr:~/repositories/haquery/db] svn% ls -alF
total 5430
drwxrwx--- 2 svn Proto2004 512 May 26 07:05 ./
drwxrwx--- 7 svn Proto2004 512 May 15 02:54 ../
-rw-rw---- 1 svn Proto2004 1740 May 15 02:54 DB_CONFIG
-rw-rw---- 1 svn Proto2004 49152 May 26 07:05 changes
-rw-rw---- 1 svn Proto2004 32768 May 26 07:05 copies
-rw-rw---- 1 svn Proto2004 1046269 May 26 04:19 log.0000000001
-rw-r--r-- 1 poppenhe Proto2004 1040863 May 26 06:12 log.0000000002
-rw-r--r-- 1 poppenhe Proto2004 741400 May 26 06:50 log.0000000003
-rw-rw---- 1 svn Proto2004 32768 May 26 07:05 nodes
-rw-rw---- 1 svn Proto2004 32768 May 26 07:05 representations
-rw-rw---- 1 svn Proto2004 32768 May 26 07:05 revisions
-rw-rw---- 1 svn Proto2004 2392064 May 26 07:05 strings
-rw-rw---- 1 svn Proto2004 32768 May 26 07:05 transactions
-rw-rw---- 1 svn Proto2004 32768 May 26 07:05 uuids
and the verify for user 'svn':
[vcr:~/repositories] svn% svnadmin verify haquery/
svn: Berkeley DB error while opening environment for filesystem
haquery/db:
Permission denied
and the verify for user 'poppenhe':
[vcr:~svn/repositories] poppenhe% svnadmin verify haquery/
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
* Verified revision 3.
* Verified revision 4.
* Verified revision 5.
* Verified revision 6.
thank you for consideration!
- paul oppenheim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by John Peacock <jp...@rowman.com>.
Paul Oppenheim wrote:
> just my 2¢ -- naturally i'm gonna be port-forwarding a svnserve -d
FYI, for a purely *nix style way of making this transparent to the users, place
the following script in a directory located in the PATH before the location of
the normal svn executable:
#!/bin/sh
ssh -f -L 3690:127.0.0.1:3690 your.server.name sleep 10 2>/dev/null
/usr/local/bin/svn $@
Name that file "svn" and you are good to go; the first line sets up a
short-lived (you can adjust that time down) tunnel, which the second line will
use that tunnel for this transaction. I redirected stderr so that if I run this
script more often than once every 10 seconds, I won't see the error that ssh
cannot create a new tunnel on the same port.
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by John Peacock <jp...@rowman.com>.
John Peacock wrote:
> I could certainly see a new option to svnserve to run in a true proxy
> mode via tunneled connections. That would work the way you expect it
> to, but would require a server daemon, so it wouldn't fit everyone's
> needs (anymore than the current implementation does). The same remote
> svn+ssh:// URL could be used, but it would be up to the site
> administrator to decide which way to go. You could even have the
> svnserve proxy for some other machine running the conventional svn
> daemon...hmmm....
Thinking this over (and re-reading the docs), I see that it won't work with the
same URL on the client, since the only think the client knows to do is use XXX
to connect to the remote server and run 'svnserve -t' to request tunneling. It
would have to be a new client-side URL entirely; svn-ssh:// anyone? ;)
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by John Peacock <jp...@rowman.com>.
Paul Oppenheim wrote:
> So, my suggestion to you, or whoever else is following, is that since
> svn:// works with a daemon, why not have svn+ssh:// work with a daemon
> as well? Just have it act like a port-forwarded svn:// -- that's
> probably how most people expect it to work anyway.
I agree it's confusing; I believe the origin of svn+ssh:// working the way it
does is for sites where *no* extraneous daemons are permitted. As such, it is
an extension to the way that file:// protocol functions for local users. This
way, remote users use svn+ssh:// via their existing ssh keys, running the code
as themselves. And local users use file://, again running the files as themselves.
The difference is that remote users need to run a network protocol, hence the
use of svn+ssh:// for the remote client (as opposed to having file+ssh://). It
just so happens that 'svnserve -t' functions as a sort of svn:// proxy as well
as a standalone daemon.
I could certainly see a new option to svnserve to run in a true proxy mode via
tunneled connections. That would work the way you expect it to, but would
require a server daemon, so it wouldn't fit everyone's needs (anymore than the
current implementation does). The same remote svn+ssh:// URL could be used, but
it would be up to the site administrator to decide which way to go. You could
even have the svnserve proxy for some other machine running the conventional svn
daemon...hmmm....
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Paul Oppenheim <po...@umich.edu>.
Hello again,
I did read the chapter, i understand that svn+ssh:// makes a remote
connection then acts like file://. But then you say that file:// breaks
permissions by default if you have multiple users, and requires a hack
to work properly. That's where my original question came in -- I
already knew how svn+ssh:// worked, only i didn't know it was broken
because file:// was broken. I was then puzzled why svn+ssh:// didn't
act like svn://, so i made that suggestion. I was then confronted that
I was confused about how svn+ssh:// worked. I'm not confused, i'm
asking why doesn't it work like the port-forwarding you described. I
imagine many people are befuddled by this same ordeal, and would have
no problem running a daemon if it means it will work by default :) 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."
So, my suggestion to you, or whoever else is following, is that since
svn:// works with a daemon, why not have svn+ssh:// work with a daemon
as well? Just have it act like a port-forwarded svn:// -- that's
probably how most people expect it to work anyway. Then it won't be a
problem to the migrating CVS users who think "hey, this looks like a
tunneled pserver setup." I mean, it even has svn:// in the name
already, it's a logical step on the user-side (as opposed to
file+ssh:// :P). It also takes care of that whole "single point of DB
access" problem you mentioned earlier.
just my 2¢ -- naturally i'm gonna be port-forwarding a svnserve -d or
using the umask hack until this change is made. I just wish that's what
it did in the first place, because that's what my impression was of it.
It's also the only way this will work for people right off the bat,
until the fixes Greg mentioned are made to file://.
To you, and all who helped, i didn't realize that file:// had
permission problems, thanks for helping me realize that was the
problem, not anything else crazy I was doing.
- paul
On May 26, 2004, at 5:39 PM, Ben Collins-Sussman wrote:
> Have you read the book? Specifically chapter 6?
>
> svn+ssh:// doesn't "create an ssh tunnel and connect to an svnserve
> daemon that's already running." It uses ssh as if it were the 'rsh'
> command. It launches a temporary, private 'svnserve' process running
> as
> *you*, which then opens the database. Thus it's no different than
> using
> a file:/// URL on the server box. And if your umask and group
> membership isn't just right, you risk messing up permissions for
> everyone else.
>
> That said, you *could* use ssh port-forwarding, which is what I think
> you're imagining. You could set 'svnserve -d' running as single user
> on
> a machine behind a firewall, then set up ssh to do port-forwarding.
> Just forward local port 3690 to remotehost port 3690, and connect to
> svn://localhost/. That creates a permanent ssh "tunnel" between the
> two
> boxes, over which you connect to the svnserve daemon.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-26 at 16:35, Paul Oppenheim wrote:
> regarding the last line of your message -
>
> Then why doesn't it work that way?
>
> I would have no problem keeping the svnserve daemon running as user
> 'svn' and have clients connect to it. That's actually how I expected it
> to run the first time I tried to bring it up. Here's me: "why isn't
> svnserve -t working? svnserve -d does, i don't get it"
>
> My problem is keeping an open port other than ssh. I was under the
> impression that "tunnelling" was exactly that. So we return to the last
> line of your message -- then why doesn't it work that way?
Have you read the book? Specifically chapter 6?
svn+ssh:// doesn't "create an ssh tunnel and connect to an svnserve
daemon that's already running." It uses ssh as if it were the 'rsh'
command. It launches a temporary, private 'svnserve' process running as
*you*, which then opens the database. Thus it's no different than using
a file:/// URL on the server box. And if your umask and group
membership isn't just right, you risk messing up permissions for
everyone else.
That said, you *could* use ssh port-forwarding, which is what I think
you're imagining. You could set 'svnserve -d' running as single user on
a machine behind a firewall, then set up ssh to do port-forwarding.
Just forward local port 3690 to remotehost port 3690, and connect to
svn://localhost/. That creates a permanent ssh "tunnel" between the two
boxes, over which you connect to the svnserve daemon.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Paul Oppenheim <po...@umich.edu>.
regarding the last line of your message -
Then why doesn't it work that way?
I would have no problem keeping the svnserve daemon running as user
'svn' and have clients connect to it. That's actually how I expected it
to run the first time I tried to bring it up. Here's me: "why isn't
svnserve -t working? svnserve -d does, i don't get it"
My problem is keeping an open port other than ssh. I was under the
impression that "tunnelling" was exactly that. So we return to the last
line of your message -- then why doesn't it work that way?
- paul
On May 26, 2004, at 3:51 PM, Ben Collins-Sussman wrote:
> There's no other way. svn+ssh:// isn't for the faint-hearted. There's
> no magic way to make it "work out of the box".
>
> CVS has similar problems out-of-the-box, assuming you have a bunch of
> system users all reading/writing RCS files. It's just the natural
> side-effect of a bunch of users trying to directly access database
> files.
>
> The only "clean solution" is to allow a *single* process to own and
> access the database.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-26 at 14:48, Paul Oppenheim wrote:
> The current permissions and access system is very confusing to those
> who are developers, not unix sysadmin gurus. As it is, svn+ssh does not
> work correctly out of the box. Why does it work the way it currently
> does (that is, designed to ignore that it needs some type of umask
> intervention), and is there change in the wind? Do I have to do the
> somewhat dodgy umask shuffle, or is there another way?
There's no other way. svn+ssh:// isn't for the faint-hearted. There's
no magic way to make it "work out of the box".
CVS has similar problems out-of-the-box, assuming you have a bunch of
system users all reading/writing RCS files. It's just the natural
side-effect of a bunch of users trying to directly access database
files.
The only "clean solution" is to allow a *single* process to own and
access the database.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by John Peacock <jp...@rowman.com>.
Paul Oppenheim wrote:
> The current permissions and access system is very confusing to those who
> are developers, not unix sysadmin gurus. As it is, svn+ssh does not work
> correctly out of the box. Why does it work the way it currently does
> (that is, designed to ignore that it needs some type of umask
> intervention), and is there change in the wind? Do I have to do the
> somewhat dodgy umask shuffle, or is there another way?
It might help you if I emphasize that svn+ssh:// is exactly equivalent to
multiple local users using file://. In other words, you still have to be very
careful about permissions, even if you initially set up the repository exactly
right the first time. All steps in the svn+ssh:// server checklist are necessary.
One thing you can consider is putting your svnserve wrapper in a different
directory located earlier in the user's effective path. Thus you don't need to
move the executable (so you can still use the ports to update), but you can
still adjust the umask correctly. You can also reconsider using svnserve in the
first place; the ra_dav access method (http://) has much better granularity for
security (because Apache already provides that), including using client
certificates for authentication.
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
>
> How could a daemon authenticate a local user?
>
Well, the obvious suggestion is using the framework provided by PAM, but
that's probably not a dependency we would want to consider...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Paul Oppenheim <po...@umich.edu>.
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
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Greg Hudson <gh...@MIT.EDU>.
[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
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Paul Oppenheim <po...@umich.edu>.
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.
a daemon authenticates a local user already if you svn://localhost/...
- paul
On May 26, 2004, at 6:12 PM, Greg Hudson wrote:
> On Wed, 2004-05-26 at 17:54, Paul Oppenheim wrote:
>> But why not use a method that already exists? The only reason i'm
>> using
>> ssh is that its security is guaranteed by a much larger user base, and
>> i trust having its port open far more than svnserve -d's port (3970?).
>> If there was an svnserve daemon that could authenticate a local user
>> (and not open a remote port!), it would be very handy to many folks.
>
> How could a daemon authenticate a local user?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-05-26 at 17:54, Paul Oppenheim wrote:
> But why not use a method that already exists? The only reason i'm using
> ssh is that its security is guaranteed by a much larger user base, and
> i trust having its port open far more than svnserve -d's port (3970?).
> If there was an svnserve daemon that could authenticate a local user
> (and not open a remote port!), it would be very handy to many folks.
How could a daemon authenticate a local user?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Paul Oppenheim <po...@umich.edu>.
Greg,
I think your ideas are very good solutions to the problem, but why not
just have an svnserve daemon running on the remote box that waits for
local connections? I agree with all of this; i certainly don't want
permissions to bork my database, i would certainly agree to having only
one user access the database. I already setup an svn user to do just
that :)
But why not use a method that already exists? The only reason i'm using
ssh is that its security is guaranteed by a much larger user base, and
i trust having its port open far more than svnserve -d's port (3970?).
If there was an svnserve daemon that could authenticate a local user
(and not open a remote port!), it would be very handy to many folks.
just my suggestion to what appears to be a big stopping point for a few
people
- paul
On May 26, 2004, at 4:41 PM, Greg Hudson wrote:
>> The current permissions and access system is very confusing to those
>> who are developers, not unix sysadmin gurus. As it is, svn+ssh does
>> not work correctly out of the box. Why does it work the way it
>> currently does (that is, designed to ignore that it needs some type
>> of umask intervention), and is there change in the wind? Do I have
>> to do the somewhat dodgy umask shuffle, or is there another way?
>
> Lots and lots of people run into this problem, and yes, it sucks.
> There are three changes in the wind:
>
> * In svn 1.1, there will be an svnserve --tunnel-user option, which
> you can use in combination with the "command" directive in the
> authorized_keys file to set up svn+ssh so that you have one system
> account with many users, each user having a distinct key.
>
> * In svn 1.1, there will be an alternate FS back end (FSFS) which
> does not use BDB and does not have the umask requirement. (It
> still has the requirement to set the db directories g+s if you're
> using group access permissions, so things may quite not work "out
> of the box." Not certain if there's anything we can legitimately
> do anything about that. Anyway, it's a lot closer.)
>
> * Some future version of BDB is supposedly going to have a flag we
> can set so that new logfiles are chmodded after creation. We have
> no idea when that will happen, though.
>
> We have considered stopgap fixes, like adding a umask directive to
> svnserve.conf, but they are half-measures and come with a lot of
> associated pain (umask isn't portable and you can't have separate
> umasks for each repository if the server is running in threaded mode),
> so we haven't implemented them.
>
> We've also considered adding better diagnostics (checking to make sure
> you have write access to the DB files before trying to open the
> database, and giving a better error message than "your DB is corrupt,
> run recovery"), and I think approved the idea, but I believe failed to
> implement them out of lameness.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Greg Hudson <gh...@MIT.EDU>.
> The current permissions and access system is very confusing to those
> who are developers, not unix sysadmin gurus. As it is, svn+ssh does
> not work correctly out of the box. Why does it work the way it
> currently does (that is, designed to ignore that it needs some type
> of umask intervention), and is there change in the wind? Do I have
> to do the somewhat dodgy umask shuffle, or is there another way?
Lots and lots of people run into this problem, and yes, it sucks.
There are three changes in the wind:
* In svn 1.1, there will be an svnserve --tunnel-user option, which
you can use in combination with the "command" directive in the
authorized_keys file to set up svn+ssh so that you have one system
account with many users, each user having a distinct key.
* In svn 1.1, there will be an alternate FS back end (FSFS) which
does not use BDB and does not have the umask requirement. (It
still has the requirement to set the db directories g+s if you're
using group access permissions, so things may quite not work "out
of the box." Not certain if there's anything we can legitimately
do anything about that. Anyway, it's a lot closer.)
* Some future version of BDB is supposedly going to have a flag we
can set so that new logfiles are chmodded after creation. We have
no idea when that will happen, though.
We have considered stopgap fixes, like adding a umask directive to
svnserve.conf, but they are half-measures and come with a lot of
associated pain (umask isn't portable and you can't have separate
umasks for each repository if the server is running in threaded mode),
so we haven't implemented them.
We've also considered adding better diagnostics (checking to make sure
you have write access to the DB files before trying to open the
database, and giving a better error message than "your DB is corrupt,
run recovery"), and I think approved the idea, but I believe failed to
implement them out of lameness.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2
Posted by Paul Oppenheim <po...@umich.edu>.
> Have you read the last section in chapter 6, and gone down the
> svn+ssh:// checklist?
I skipped that section, because it is entitled "supporting multiple
access methods" and I only have one access method. Since you are the
author, I hope it would not be out of place to suggest renaming the
section :)
http://svnbook.red-bean.com/svnbook/ch06s03.html#svn-ch-6-sect-3.3
I have followed the first step of the checklist, but I thought the
other parts were disconcerting. Since I am using a FreeBSD install, if
I were to move the binary file for svnserve, it would disable me from
portupgrading it. As far as I know, on most UNIXes, moving the binary
will upset the upgrading process, or at least end up getting your
script replaced with the upgrade.
If you look at my previous email again, you will see that SVN creates
broken permissions on its own, out of the box. I didn't go in there and
tell berkeley DB to 'chmod g-w log.*' :-D
The current permissions and access system is very confusing to those
who are developers, not unix sysadmin gurus. As it is, svn+ssh does not
work correctly out of the box. Why does it work the way it currently
does (that is, designed to ignore that it needs some type of umask
intervention), and is there change in the wind? Do I have to do the
somewhat dodgy umask shuffle, or is there another way?
- paul
On May 26, 2004, at 11:53 AM, Ben Collins-Sussman wrote:
> On Wed, 2004-05-26 at 10:17, Paul Oppenheim wrote:
>> Hello SVN'ers,
>>
>> I'm having a problem with an SVN 1.0.2 repository that is living on a
>> FreeBSD 5.2 server. My team's repository is administered by a user
>> named 'svn' and has a group of 'Proto2004'. Two users that are also in
>> group 'Proto2004' are 'poppenhe' and 'woodardj'. When user 'poppenhe'
>> makes a commmit, user 'woodardj' cannot then use the repository.
>>
>> I've examined the repository, and the problem seems to be a
>> permissions
>> problem. The only time the permissions were manually modified was when
>> the repository was created. After creation, I did a 'chown -RP
>> svn:Proto2004 haquery/' to make the repository accessible to the users
>> of the group. Is that incorrect? The access method is restricted to
>> svn+ssh.
>
> Have you read the last section in chapter 6, and gone down the
> svn+ssh:// checklist?
>
> http://svnbook.red-bean.com/svnbook/ch06s05.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Somewhat corrupted repository: Berkeley DB Permissions errors
on SVN 1.0.2
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-26 at 10:17, Paul Oppenheim wrote:
> Hello SVN'ers,
>
> I'm having a problem with an SVN 1.0.2 repository that is living on a
> FreeBSD 5.2 server. My team's repository is administered by a user
> named 'svn' and has a group of 'Proto2004'. Two users that are also in
> group 'Proto2004' are 'poppenhe' and 'woodardj'. When user 'poppenhe'
> makes a commmit, user 'woodardj' cannot then use the repository.
>
> I've examined the repository, and the problem seems to be a permissions
> problem. The only time the permissions were manually modified was when
> the repository was created. After creation, I did a 'chown -RP
> svn:Proto2004 haquery/' to make the repository accessible to the users
> of the group. Is that incorrect? The access method is restricted to
> svn+ssh.
Have you read the last section in chapter 6, and gone down the
svn+ssh:// checklist?
http://svnbook.red-bean.com/svnbook/ch06s05.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org