Creating Per-User repositories
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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Creating Per-User repositories
How about writing a course setup script (that reads in a list of users in the course) and sets up a pserver for each student (say on ports 1100+), on a unique port, with --allow-root=/home//cmvsroot. Have each pserver setup to run as that user's account. If you are not concerned with packet sniffers and users properly protect .cvspass, this might work. Users have complete control over their own repository and can give others access (via the password file). Also, the users can lockdown CVSROOT from the command line (except emptydir and history), to prevent others from having CVS access to commit new CVSROOT files. Just some quick thoughts, might have overlooked something obvious. --- Tiago Alves Macambira <[EMAIL PROTECTED]> wrote: > 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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Creating Per-User repositories
[ On Wednesday, January 30, 2002 at 16:55:56 (-0200), Tiago Alves Macambira wrote: ] > Subject: Creating Per-User repositories > > Perhaps it is not really all that complitated to do this with pserver, It would be MUCH easier, and far more secure overall, to just use SSH. > as I could easily put each user repository as a directory inside the Yes, each user's $CVSROOT could be within their $HOME with SSH too. > [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. You don't need user-editable password files with SSH -- they don't exist there anyway! > [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. If you need ACLs (and you maybe do to get all the functionality you desire), then why don't you choose a platform which supports them!?!?!?!? > [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?! Use ACLs if you need them. They're user-controllable. Choose a suitable platform that implements all of the functionality you need. Don't base your platform choice on irrelevant factors! -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Creating Per-User repositories
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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Creating Per-User repositories
[ On Thursday, January 31, 2002 at 12:47:22 (-0800), Noel Yap wrote: ] > Subject: Re: Creating Per-User repositories > > 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. Oh, but it will Noel -- at least so long as the server system supports full filesystem ACLs (at least on the filesystem used for $HOME). With ACLs users can grant read and/or write access to ano other user(s) to explicit directories in their $CVSROOT. It might be nice to have a pre-canned little script that can do all the right things w.r.t. how CVS obeys permissions and ownerships though, especially if the users are students. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Creating Per-User repositories
My point was that students can't grant any access to anyone not having an account on the system (I mistakenly said "to anyone not having a login on the system" in my previous email). I'm assuming students don't have authorisation to create system accounts. Noel --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > [ On Thursday, January 31, 2002 at 12:47:22 (-0800), > Noel Yap wrote: ] > > Subject: Re: Creating Per-User repositories > > > > 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. > > Oh, but it will Noel -- at least so long as the > server system supports > full filesystem ACLs (at least on the filesystem > used for $HOME). > > With ACLs users can grant read and/or write access > to ano other user(s) > to explicit directories in their $CVSROOT. > > It might be nice to have a pre-canned little script > that can do all the > right things w.r.t. how CVS obeys permissions and > ownerships though, > especially if the users are students. > > -- > Greg A. Woods > > +1 416 218-0098; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of > the Weird <[EMAIL PROTECTED]> > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Creating Per-User repositories
[ On Friday, February 1, 2002 at 07:00:08 (-0800), Noel Yap wrote: ] > Subject: Re: Creating Per-User repositories > > My point was that students can't grant any access to > anyone not having an account on the system (I > mistakenly said "to anyone not having a login on the > system" in my previous email). I'm assuming students > don't have authorisation to create system accounts. I think you're dreaming about problems which should not exist. I believe it was implied in the original post that all authorised students would implicitly be given permission to access the CVS server. If one uses SSH this this means they will all have accounts. Indeed this is one of the benefits of SSH -- students cannot authorised unauthorised users to use the server! ;-) BTW, Noel, the top-quoting you do with your MUA is getting a bit painful, again. :-) Please trim your posts down to only the text necessary to maintain the context not written into your reply! -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Creating Per-User repositories
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > I think you're dreaming about problems which should > not exist. I > believe it was implied in the original post that all > authorised students > would implicitly be given permission to access the > CVS server. If one > uses SSH this this means they will all have > accounts. Indeed this is > one of the benefits of SSH -- students cannot > authorised unauthorised > users to use the server! ;-) Please stop trying to pick fights. This was from the original post: >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. You may have inferred that "all authorised students would implicitly be given permission to access the CVS server," but no such thing was implied. Indeed, the original post left it open that students can grant or deny access to other students and grant or deny access to those not having system accounts. My reply made no assumptions and was meant to cover the bases in order to be most helpful to the poster. Noel __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
