[Top][All Lists]

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

Re: Question on user repository restrictions

From: Mark D. Baushke
Subject: Re: Question on user repository restrictions
Date: Tue, 27 Jun 2006 03:27:12 -0700

Hash: SHA1

Luis <address@hidden> writes:

> Thank you all for such great feedback.
> We will start the setup before September, so that it can be used for
> the next year's course... Then I will tell you how we did it.

This would be interesting information.

> BTW, it is a great idea to base the assignment delivery directly
> through CVS, using a version ID, for example. I guess that versions
> record the date and time when they are created, so this will also help
> ensure that they deliver the code on time.

Yes. Although, you might allow them to tag the latest revision of the
files that they believe work and move the tags as more features are
added. There is no reason to force them to make last-minute changes
always need to work especially if they are working on any extended
features for 'extra credit' or the like.

> About securing the connection: Eclipse supports "pserver", "ext" and
> "extsh". 

Actually, you mean ":pserver:", ":ext:", and ":extssh:" are the
supported Eclipse methods. You may also have the option of ":kserver:"
or ":gserver:" if your systems use Kerberos IV or Kerberos V.

You probably want to be sure to use Eclipse 3.1 or better. WTP 1.0
supports Eclipse 3.1.x. WTP 1.5 is supposed to support Eclipse 3.2.

Note: I have NOT used Eclipse myself.

> Which one is more secure? 

The least secure is :pserver: as it keeps a copy of the user's password
in a $HOME/.cvspass minimally encoded. On a shared system, or one that
is able to sniff communications traffic, it will become quickly easy for
a cheat to impersonate another user.

The next least secure is :ext: with CVS_RSH=rsh (i.e., the berkeley
rlogin/rsh system). It is farily easy to fool an rsh from a system
where the user owns the 'root' login if it can be considered 'trusted'
by the rlogin system, then anyone may impersonate anyone else.

The next most secure is probably :ext: with the CVS_RSH=ssh (or, windows
clients may use Putty instead of ssh as the transport) which is another
way to specify the :extssh: protocol. This method very secure unless the
users share systems and one or more of them is able to run as root on the
shared system in which case all bets are off.

The most secure is probably :gserver: which uses a
ticket-granting-ticket from the KDC to authenticate the user.

> Do they have any extra requirements?

The SSH system will typically mean that the server will need to support
the SSHv2 (I recommend against allowing the SSHv1 protocol) protocol.

> And would that work in CVSNT?

All of the above should work with either CVS or CVSNT clients or
servers, depending on configurations of the host environments.

If your server is CVSNT, then you have a few additional methods that
might be available to authenticate with the ActiveDirectory Windows
system if that is in general use at your location.

        Good luck,
        -- Mark

> Regards,
> Jeremie Le Hen wrote:
> > Hi Luis,
> >
> > > Here is the context of the problem: I teach Java and J2EE at a
> > > university. My students use Eclipse+WTP as the development environment,
> > > but the lab PCs are shared and it is currently very messy for them to
> > > keep their eclipse projects: the lab PCs are cleaned after every boot,
> > > so the students must manually backup all their work.
> > >
> > > That is why I am thinking of setting up a CVS server. In addition to
> > > simplify their work so they can focus on learning, they will no longer
> > > have the typical excuse of "I lost my hard drive and the practical work
> > > I had to present today was there".
> > >
> > > The problem is that this is not a typical CVS setup, since each student
> > > should only be able to see the code he submits, and not be aware of any
> > > other code from other students (otherwise they would copy the code from
> > > the good students).
> > >
> > > ...And here goes the question: how should I setup CVS in order to
> > > support that approach? Is there a way to configure the user/password
> > > files so that a given CVS resource can only be seen by the user that
> > > created it? They should not be able even to see the directory structure
> > > of other student's projects, as they would learn how the project is
> > > structured (in Java, a file usually corresponds to an object).
> > > Or maybe the best approach is to setup a separate repository for each
> > > student? If so, how scalable is that? My classes have 20 to 40
> > > students, and if this approach works fine it may be used by other
> > > groups and add up to, say, a total of 120 students.
> >
> > As a side note to what has been answered, I would add that you should
> > really rely on strong cryptgraphy.  The cryptography scheme applied
> > to CVS pserver is very weak and can be deciphered pretty easily with
> > the dsniff tool.  Given that students are often more arful than
> > hardworking, I think you should not provide them an easy way to
> > steal their schoolmate work, especially those who are hardworking and
> > not willing to fob their work off on the others.
> >
> > Best regards,
> > --
> > Jeremie Le Hen
> > < jeremie at le-hen dot org >< ttz at chchile dot org >
> _______________________________________________
> info-cvs mailing list
> address@hidden
Version: GnuPG v1.4.3 (FreeBSD)


reply via email to

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