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 email@example.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