Classification: UNCLASSIFIED [EMAIL PROTECTED] wrote: > anything as complex as CVS. Without too much effort, anyone > with access > to the repository can plant commands that you'll end up > running as root > without even knowing it.
can you elaborate on this? what magic files is the cvs server going to be looking for? Are we talking about cvs running the various support scripts (loginfo, commitinfo etc)? That I understand. I guess it wasn't clear, the CVS *server* is NOT running as root. only the client is. What kind of tricks is the client up to then? > Some mucking about with permissions makes sense in the environment CVS > was intended for. For example, CVS makes the RCS files in the > repository read-only (just like RCS does) to prevent people > from mucking about with them. these kind of games don't make sense to me. the parent directory in the repository is frequently if not almost always group-write (because of CVS artificial design limit). Taking the 'w' bit off a file isn't going to stop anything. And if the repository is remote, the tactic is even more of questionable value is it not? But by implementing this you've artificially limited the cvs admin's options by a considerable amount. eg. if the parent dir is g=RX then by tagging individual files with g=RW I can support 2 distinct classes of persons within the same group definition with the potential to add another: those that are members of the group and can read all files, and those that can edit certain and possibly all files. If the gid of the parent dir is different than the files contained within, I have another group that can add files to the collection to boot. This really isn't an unreasonable or overly complex setup. If one's needs are trivial then you don't care if you have this or not. > It also allows you to ask for checked-out > files to be read-only. that's fine. Does not need chmod to do that but rather the proper flag to fopen() which we do for the most part I think. > It makes a feeble attempt to track execute > permission since > it's convenient to be able to execute a script that you've > just checked > out. Feeble indeed. if umask&CVSUMASK=027 for example, a script that was originally 555 or 755 is now 530 or 730. oops!! It's still executable by the user, but what what happens when I check that file back in? And wasn't this supposed to be a build matter? I will grant you that it is nominally user-friendly not to have to make the script executable before being able to use it, but the correct way is to support 'mode' as an attribute of the file to be set just like commit messages are and NOT simplistically grabbing them off the working file which was where the whole mess started. > It also makes a feeble attempt to track read/write permission to > provide a modicum of privacy from prying eyes. It's the comingling of repository permissions with those of the working dir which is the fundamental fallacy here. Visibility within the working dir is the user's umask&CVSUMASK's problem and his savvy with respect to his work space and the nature of the files. The repository content's visibility and control over checkout/in is the CVS admin's job and responsibility and is 100% independent of the developer. The developer should not have to resort to a script to pound the checked out contents into a suitable form when 3 simple fields can take care of 90% of the problem regardless of what the cvs admin might be doing/have done to the repository to suit his requirements. Yes the two entities cooperate but the programmers really have no business dictating preconditions to the admin (oh, please treat 'x' as special, or don't set CVSUMASK to such and such, etc). The admin needs to know who should have access and to what and if he wants to be tightfisted about permissions and cross-project visibility that's his call. How the content shows up in the working dir is the developer's problem. Therefore the developer has only two paths available to him: tagging the file with some fields, or writing a script to munge things. CVS wasn't designed with security in mind as has been said. Well then CVS has no business interjecting itself where it don't belong and especially making feeble attempts at it and pretending to do something. Do it right, or don't do it at all. Don't get me wrong, I like CVS a lot. I'm just heavily annoyed at inconsistent behavior and don't like band-aids or hacks which are worse than the disease when design can obviate them. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs