info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [Cvsnt] :ntserver: from unix/linux accessible?


From: Jonah Tsai
Subject: Re: Re: [Cvsnt] :ntserver: from unix/linux accessible?
Date: Fri, 07 Sep 2001 06:30:43 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010131 Netscape6/6.01

From: address@hidden <mailto:address@hidden> (Tony Hoyle)
Subject: Re: [Cvsnt] :ntserver: from unix/linux accessible?
Date: Thu, 06 Sep 2001 11:11:25 GMT
Organization: cvsnt.org news server
To: address@hidden <mailto:address@hidden>

On Thu, 6 Sep 2001 07:31:12 +0000 (UTC), "Thomas Singer"
<address@hidden> <mailto:address@hidden> wrote:

 >Hello,
 >
 >I'm not familiar with the :ntserver:, only :pserver:.
 >
 >Is it possible to access cvsnt in :ntserver: mode indipendent of the client
 >os (no matter, whether there are some cvs executables that support this)? If
 >so, where I can find documentation, how the protocol is defined (per
 >tcp-ip?)?
 >

In theory someone could build an extension to samba that could open
named pipes, but I don't think anyone has done any work in this area
yet.  Maybe try asking on the samba list to see if it's possible..

Tony

I may be biased, but why not try the other way around, i.e. host CVS on Linux and access it from Windows? Security concern?

I have modified cvs-1.11.1p1 to "enable" kerberos on Windows (gserver, the GSSAPI code is already there for Unix.), which "should" allow Unix CVS client access to NT CVS server. However, I haven't tested this reverse route yet. Afterall, my purpose is to allow Windows cvs clients to access Unix servers securely; not the other way around, but there is no reason for the reverse route not to work properly.

When I was working for a software company in Texas, what prevented me from deploying CVS was precisely this - no secured way of accessing Unix CVS server from Windows. I mean, as a professional over-paid, under-dressed, under-hygined software developer, I couldn't tell my boss -- "well, we can hack around and use SSH... so, buy a lot of SSH in order to use a free software", especially not under the situation that the company spent literally millions of dollars on ClearCase for Windows (US dollars, I heard, ok?).

I have been emailing back and forth with Alex @ wincvs.org for awhile. He suggests that I post a message here to raise interests, especially Tony's. ;) So, I might as well take this chance to post it here.

So, here goes the post that I intended to send out.

Anybody interested please say Aiyh.

- Kerberoized CVS on Windows compiled from cvs-1.11.1p1 source code distro. Some few lines of souce code changed, plus some modifications to MSVC 6 project files (converted from the original VC 4 project files). - I have tried this with a W2K client, a RedHat Linux 6 client, and a Sparc Solaris 2.8 server. (The Solaris 2.8 machine hosts SUN's implementation of KDC and kerberoized CVS.) - Want to see the modifications incorporated into CVS or CVSNT souce code tree.

I have been talking to Alex @ wincvs.org and he suggested that I post a message on cvsnt and cvsgui lists to raise interests. I decided to drop cvsgui in favor of info-cvs to see if there are interests there.

The source files modified are:
  src/client.c
  src/login.c
  src/server.c
  windows-NT/config.h

Most of these modificaitons are trivial #if's, in order to accomodate MIT's krb5 on Windows and MSVC 6. There are probably less than 50 LOC of modifications.

The thing about this is really not how much code needs to be patched, it is, IMHO, a proper build/test environment with Kerberos. See, , will you take the binary I build as the "official" build? I don't think it's a good idea to just take anybody's build as the official.

Why bother having a kerberoized CVS on Windows? Cross-platform security. There are currently 6 common ways people do when it comes to CVS security: (not counting ntserver which is present only in cvsnt, and I admit that I don't know anything about it. ;)
   1. NFS.
   2. SMB.
   3. Pserver.
   4. RSH.
   5. SSH.
   6. Gserver (GSSAPI, currently Kerberos).

Which method suites your needs depends on your setup. The argument about the advantages and disadvantages of each method is quite long and sometimes subjective. Unless a lot of people want to hear my 2 cents on this, I will not go into the argument now. I reconsider only SSH and GSSAPI methods secured enough to put the server out under public bombardment. In any case, I consider GSSAPI the most direct and proper authentication/encryption method of the above 6.

I will give the most compelling reason (for me at least) right now for Kerberos vs. SSH, barring all the extra pain in the *** associated with Kerberos. With SSH, you either have to have active login accounts on the CVS server, or you have a separate SSH login server which port-forwards CVS traffics to the real CVS server. Either way, what's my business there logging into one of your machines while all I am supposed to be doing is checking in/out source files? This is especially true with free software projects. You know, give me a login shell, I can do a lot more that you want me to be able to.... BAD IDEA! If it's a source control server, then NO REGULAR LOGINS!!! With Kerberos, you give cvs users accounts on the CVS server, but lock them out such that they cannot login but will be able to check in/out files on your source tree via CVS, provided proper permissions are set on the repository and pam.conf is tweaked correctly. That is, CVS runs as root authenticting users via Kerberos and "su" to those users to check in/out files, assuming CVS itself is secured enough to run as root.

I am sure somebody out there can come up with some more creative ways of using SSH without the disadvantage I just mentioned above. But, the real issue is that the only secured authentication method CVS provides natively is gserver (again, barring ntserver). If there is no other way of doing it securely, well, SSH is a nice and easy way to go around the authentication problem.

In any case, SSH is one way "around" the authentication problem, Kerberos is another attractive way for organizations that already swallowed the Kerberos pill or are willing to swallow it.



Jonah Tsai




reply via email to

[Prev in Thread] Current Thread [Next in Thread]