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_ellis at franklin.com wrote: > 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... Hehehe... well, you're use is a tad eccentric. > Reason: the box is *not* dedicated, every user will have shell > access to the machine, I need this feature for other purposes. Oh well... > 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. Use :pserver: (or whatever) to access localhost. Use file-level ACLs to keep your users out... only allow the cvsnt service to read/write the repository. > > 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. That's the simplest solution. > > 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? All cvs[nt] networking happens via port 2401 (unless using :local: which directly access the repository). If you just happen to use a secure protocol (e.g. :sserver:) then the data link is encrypted. Unlike http/https, the plain and encrypted cvs stuff happens over the same port. -- David Somers typographer/programmer/whatever