[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [Cvsnt] :ntserver: from unix/linux accessible?
Re: Re: [Cvsnt] :ntserver: from unix/linux accessible?
Fri, 07 Sep 2001 06:30:43 -0400
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:
>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
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..
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
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:
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
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. ;)
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
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.
|[Prev in Thread]
||[Next in Thread]|
- Re: Re: [Cvsnt] :ntserver: from unix/linux accessible?,
Jonah Tsai <=