Re: Creating Per-User repositories

[Noel Yap]

Greg has responded with most of what I wanted to say.

I do have something to add, though.  If your intent is
to have students be able to grant access to other
students, SSH is sufficient and is way more secure
than any other method out there.  However, if you want
students to be able to grant access to non-students
(ie those that won't have login id's on the system),
SSH won't cut it.

HOWEVER, any other alternative is insecure (as you've
already pointed out).  I would venture to say that any
non-security application that manages security doesn't
do so in a secure manner so the choice you're left
with with any application is security or ease of use.

Noel
--- Tiago Alves Macambira <address@hidden> wrote:
> 
> This is probably one of those questions that keeps
> appearing in this
> list with a quite annoying frequency _but_, as I
> haven't  found
> anything in the CVS documentation, neither in
> sourcefoge, savanah
> nor in google, I'll ask it here anyway - perhaps it
> is not really a 
> frequentily asked question.
> 
> 
> I and some pals are installing CVS in a box to
> provide CVS repositories
> to students of our course. We are planning on doing
> something similar to
> SourceForge[1]: every student having complete
> control over it's own
> repository and over the projects inside it, ie.,
> control on who can
> access what in his repository[4]. We also wanted for
> the repositories to be
> sowhat similar to public_html dirs: directories
> inside the user home_dir
> that have its contents's size taken in account in
> the users filesystem
> quotas.
> 
> 
> Thing is, with plain CVS tools this seems pretty
> much un-pratical and
> kind of insecure: in order to give each studant
> complete control on his
> repository,from what I've read about CVS, I would
> have to use pserver[2],
> for it is the only one that provides user
> authentication and control
> based on per-project user-editable password files.
> All the others kind
> of access seem to do not have such kind of control.
> 
> Perhaps it is not really all that complitated to do
> this with pserver,
> as I could easily put each user repository as a
> directory inside the
> user home dir and have the user and the contributors
> of its projects
> "pserver" to that repository anyway, but:
> 
>       * I would have to tell pserver that there is a new
> repository to be
>         server as well ( no problem, can be done with a
> update script
>         that edits a list of repositories to be passed to
> the pserver
>         daemon. Debian CVS admins may have a clue of what
> I'm talking about
>         more precisely )
> 
> 
>       * pserver has to be run as root? It  really  needs
> RW control
>         on the repositories, what would easly be
> "satisfied" by having
>         the repositories chgrp'ed cvs/source and having
> cvs running as
>         user nobody, group cvs/source. But then, if a
> user commits a SGID
>         script, would then this script be able to delete
> all the
>         contents of others' repositories?! Does CVS clean
> SUID and
>         SGID bits?
> 
>       * wrost, if cvs really has to be run as root to
> provide the
>         functionallity we want, by editing a project
> CVSROOT/passwd
>         file and malicious setting the "system/real user"
> ( what's the
>         word cvs documentation uses for this?!) of one
> its project
>         users, He could gain "root" access or have his
> files writen and
>         theirs size accounted on someone else's
> filesystem quota.
> 
> 
> So, is there a pratical way of doing what we want
> with CVS? I could
> always install SourceForge or Savanah code ( are the
> easy to install 
> in first place?! ) but I belive there must be a
> "simpler" ( or, more 
> elegant ) way of doing this.
> 
> 
> We would really apreciate any clues you guys can
> give us.
> 
> Thanks in advance.
> 
> 
> []s
> MaCa
> 
> [1] I've never uses SF as a project ownner, so i'm
> pretty much guessing
> how things should work there....
> 
> [2] If it was possible, I'd rather use SSH[3] as
> authentication and
> access mechanism, instead of pserver, but then i
> loose the possibility
> of having the per-project user-editable
> password/control files.
> 
> [3] If there was support for ACL[5] in linux, we
> could just ignore all those
> little issues and use CVS + SSH + all the stuff we
> need.
> 
> [4] Before anyone suggestes using groups, the
> problem with groups is that
> I would have to create a group to each project of
> each student. Ok, it
> _is_ a possible solution but i really thing that the
> groups solution
> tends to make things get messy and not to scale
> well. 
> 
> [5] OK, jfs supports ACL but isn't there a cleaner
> way?! Some sort of
> way that doesn't depends on having file-system
> conversions, backups and
> such?!
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com