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 firstname.lastname@example.org.
duane_ellis at franklin.com wrote: > 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). I think this part is already solved. > 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). This is how the cvs(nt) client talks to the cvs(nt) server, independently of whether they are on the same system or on different systems. It is a client-server application. (I suggest you forget about the :local: protocol that has been mentioned. It's a not recommended odd-man-out, so to speak, and not safe when you have many users.) Since your users have shell access to the server box, there are two slightly different scenarios (eg. WRT firewalling). 1- One is when they run a cvsnt command from the shell on the server. In this case, the cvsnt client still talks to the server through port 2401, but that happens all locally (localhost, so to speak). There's no need to "open" that port, because all traffic is local anyway. 2- The other is when they run the cvsnt client on another machine. Then that machine needs to talk to the cvsnt server -- and it does this through port 2401. So this port has to be open (inbound on the server system, outbound on the client systems). This is no different than with http. You can access your local server with your local browser without having any network connectivity on that system. But in order for your http server to be accessed from another system, you need to allow inbound connections. > I don't understand the security model you describe. Please > tell me what is supplying the encryption for that other port. It depends on which of the two cases I described you use. In case 1, it's the encryption of the shell access, presumably SSH. In case 2, it's the encryption of the cvsnt protocol. There are several possibilities. Someone else will have to explain these to you; I haven't yet found a good description of them, and since I'm running a Windows server with only Windows clients, I use :sspi:. > Remember, I am already authenticated to the system by SSH, > and unless it is secure, I can't open any other port. Many cvs(nt) servers are deployed that have their port 2401 open. How secure that is depends mainly on the protocol you are using to talk to cvsnt. > I'm sure I'm missing something... As I remember, the CVS > protocol is not secure, it is plain-text. There is no "cvs protocol" as such. There are a number of cvs(nt) protocols. Here it talks a bit about SSH http://www.cvsnt.org/manual/html/Remote-repositories.html There are other secure protocols. But it all depends on whether you want clients that run on /other/ systems to access your server, or only commands from the shells that run already on your server. In that case, you can use the plain-vanilla protocol :pserver: (not secure), as the security is already provided by the SSH access. > What provides the encryption and security for CVS transport > on port 2401? The protocol. :sspi: for example uses encryption provided by Windows. :sserver: uses SSL encryption, IIRC. > Remember this is an important part of my senario: > Server location: USA > Client locations: world wide > north-america, western europe, eastern europe, asia Not a problem, but you need to tell us how the clients run the cvs(nt) commands: only from the shell that runs on your server, or also from other systems? Gerhard