RE: Re: Write Permission on repository may encourage UNIX user to tamper with repository (SSH)

I've done this by using SSH with digital signature access. I then put a
random password on each login account, and never disclose that to
anyone. The only access allowed is via the digital signature mode of
SSH. Then the login is set up to allow SVN only, no shell.

In this case no one has the password so there isn't much reason to
change it. Then again, if I wanted to change it to a new random string
daily, I could do so on my own, it wouldn't affect anyone.

Alternatively, if your management is really confused, you could make a
shell script that allows only two operations: svn access, and the passwd
command.

                paul

From: Sachidanand Shukla [mailto:shukla.68_at_gmail.com]
Sent: Friday, May 16, 2008 1:20 AM
To: users_at_subversion.tigris.org
Subject: Re: Write Permission on repository may encourage UNIX user to
tamper with repository (SSH)

Thanks guys for the prompt reply, but issue is (if you take it as issue)
that according to our mngmt and policy in organization user should be
able to change password as and when required and so i need to create
their logins on Sol box. And the problem remains there only.

Sachidanand Shukla

On 15/05/2008, Sachidanand Shukla <shukla.68_at_gmail.com> wrote:

Hi,

I am a clearcase administrator with NCR Corp. and am currently persuing
migration of Clearcase code to SVN.

I am using svn+ssh to access repositories on Windows clients and server
is on Solaris box.

my problem is that i create a login for user on solaris box and ask him
to access repository from Windows client, but as user has access to
solaris box also (as his login is created there and repositories also
reside there) he can temper with repositries because he belongs to the
group to which repository belongs.

i tried a lot but could not succeed in protecting it.

I have configured svnserv (text file) to mask the repository path amnd
URL does not disclose full path, but even then....

i tried

1. Restricted shell

2. chroot is not possible as server is being used by other teams also

3. changed .profile etc etc.

but all in vain.

please suggest some way to solve this problem

Sachidanand Shukla

 
Received on 2008-05-16 13:05:47 CEST