Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
duane> I don't see how I can stop users from "cd /to/the/CVSROOT"
duane> and looking around.
david_sommers> cvs and cvsnt run as client-server system... so your end
david_sommers> users won't be able to cd to the repository as its on
david_sommers> another host (unless you are doing something extremely
david_sommers> dumb like making the repository available via a share
david_sommers> and using the :local: protocol.)
Hmm... "unless you are doing something extremely dumb..."
In effect, yes, I am doing something "extremely dumb"...
I seem to do that all too often... :-) don't we all...
Reason: the box is *not* dedicated, every user will have shell
access to the machine, I need this feature for other purposes.
Remember: It's a unix server, and every user will have a shell
account on the machine. They will, via their shell account, be
able to "cd /to/places" on the same file system as the
repository. Thus, I believe it is much like ":local:"
I could enforce an ":other-protocol:" for local machine
access... but that does not seem right. Maybe it is,
I'm not familure with CVSNT specific things.
I believe, as Gerhard suggests, the file system ACLs are required.
Perhaps even as far as running the CVS server as another user
(in Unix terms, as a "SETUID" application) which does have
access to the repository.
gerhard_fiedler> ... You may think about running the cvsnt
gerhard_fiedler> service as its own user, give it only access
gerhard_fiedler> to what you want cvsnt to access, and prevent
gerhard_fiedler> all other users from accessing the repository
gerhard_fiedler> (using file system ACLs).
But I have questions about Gerhard's reply.
Yes, that make sense. But.. I don't understand your other suggestion.
gerhard_fiedler> [make a hole in your firewall for] port (2401 by
default).
I don't understand the security model you describe. Please
tell me what is supplying the encryption for that other port.
Remember, I am already authenticated to the system by SSH,
and unless it is secure, I can't open any other port.
To help understand my question, here's a banking example,
I hope it makes my concern clear:
I login to the bank via a secure https server on port 443
(via SSH to my cvs server on port 22)
I can then use the unsecure port 80 to view my bank statement
(port 2401 for cvsnt protocol, for "cvs status")
To transfer funds, in or out of my account, port 80 again)
(Port 2401 for cvsnt protocol to checkin and checkout)
I'm sure I'm missing something... As I remember, the CVS
protocol is not secure, it is plain-text.
What provides the encryption and security for CVS transport
on port 2401?
Remember this is an important part of my senario:
Server location: USA
Client locations: world wide
north-america, western europe, eastern europe, asia
Am I missing something I don't know about?
The only solution I can think of is to port forward (tunnel)
this additonal port through SSH. However, that does not make
sense, it seem overly complicated, I think multiple users
attached at the same time will have problems. I'm
sure people would have already done/solved this problem.
Duane Ellis
Principal Engineer
Franklin Electronic Publishers
One Franklin Plaza
Burlington NJ 08016
email: duane_ellis at franklin.com
voice: 1-609-386-2500 x4918
skype: duane_ellis