Mark, > My point of view is that CVS should never be in the business of doing > authentication operations.
I'm turning 40 this week (yes I'm that young!) and I am finding that each year I seem to know less and less, and have fewer and fewer 'hard and fast' rules about how I believe that people should go about various tasks. When I was 21 I probably would have been happy to enter into a long debate about the 'right' answer as to where authentication should occur. Nowdays I just think that our customers are smart enough and like to have the options. CVSNT can be installed to only allow the OS to perform authentication (ssh) or it can be installed so CVSNT alone performs authentication, and many graduated levels between. If I have a personal preference it is probably the 'when in rome' philosophy: if on unix the 'way to do things' is to allow the OS to do the auth, then do that on unix, but if on windows the 'way to do things' is to have the app do the authentication (or call the authentication routines) then so do that, and so on for each platform. But just because that's my personal preference I'd never intentionaly create dependencies in CVSNT that prevented a user choosing a different install path. One of the reasons why we split out the protocols in CVSNT into separate shared libraries is so customers can even make this decision at runtime (which get's us back to the whole 'install from source' argument). If a customer doesn't install sspi.so and pserver.so then those options will never be available. > However, letting CVS (or CVSNT) run as a privileged user is never safe > in my opinion (we need to agree to disagree on this topic I guess). I personally think that my approach is the best of both worlds (but I would wouldn't I?). People who have a strong opinion can install CVSNT in a particular way so that it does not ever run as a privileged user (either by not installing pserver/sspi/etc, by setting RunAsUser, or running in a chroot jail), but those who DO want CVSNT to run as privileged can. Regards, Arthur
