Greg opines: Then you have no accountability in your CVS repository. None. You have as much accountability as you have from ssh and the passwd file: you know the name of the person (from the pserver
[ On Friday, November 15, 2002 at 11:17:10 (-0800), Shankar Unni wrote: ] No you don't. CVS is not a security application. It was not designed to be one and it cannot ensure any (i.e. not any at all)
[ On Friday, November 15, 2002 at 17:08:16 (+0100), Fredrik Wendt wrote: ] Then you have no accountability in your CVS repository. None. You cannot have security without accountability. Integrity alo
I have been racking my brain on reading documentation on CVS and so I am left with but a few questions. Ok, so, I've installed cvs on two machines. Oh, btw, my questions will be related to the follow
I've only had fair-to-middling success getting WinCVS and SSH to get along. But for what it's worth... When you log in manually with SSH, is it asking you for a password? I suspect it is. The error m
There's only one client/server protocol that's used by all the client/ server methods (pserver, ext, fork, etc.): see doc/cvsclient.*. -Larry Jones It's clear I'll never have a career in sports until
Larry> That's one of the motivations for the CVS client/server protocol -- Larry> the intent was the people should write new clients rather than trying Larry> to wrap the existing command-line clien
[ On Tuesday, October 29, 2002 at 13:47:05 (-0800), Shankar Unni wrote: ] Good questions. What are _your_ answers? Who said anything about Linux? I certainly didn't. So, which is it? Do you want some
I think this discussion has hit a wall, but I'll answer these points anyway. But I'm no longer pushing for such a feature to be included, because of the obvious reluctance of so many, so we can let t
A bit of both, I suspect. There is a school of thought (of which Greg is probably the most vociferous spokesman) that I'll call the "purists" who maintain that any security-related feature (e.g., aut
[ On Monday, October 28, 2002 at 12:02:33 (-0800), Shankar Unni wrote: ] It's all part of the same thing. In computer security you can't have any accountability without authorisation, and to do autho
accounts. Absolutely. No argument there. The issue I was talking about was not authentication, but access control (authorization), using Unix accounts. Authentication using Unix accounts is A-OK. (Us
I suppose it comes down to how you identify actual users, since the system has to know somehow about who is trying to access a module in order to allow or deny that access. The classic Unix method i
I strongly suggest using the filesystem's uid/gid and related permissions. Assign a group for each set of modules that require the same access permissions, assign a unique uid to each user (for trace
From inetd? I should hope not. This would (I believe) imply a rather serious security gap in inetd. I want to be able to debug the server process from the very beginning, but the best I can do is aft
This edition of my unprivileged server patch is the first one which might actually work, marking a sort of milestone in our progress with it here. It should be applied to the stock 1.11.2 distributio
Also, on a System-V-like server, you have to find /usr/local/cvs -type d | xargs chmod g+s # or wherever to make the "cvs" group membership that you just applied propagate to newly created files and
Hi, I'm trying to set up a cvs server, but am having some difficulties doing so. I've compiled and done the cvs init on my '/home/cvs' repository. The question is, should I set it up for pserver or k
This part is a personal preference. OTOH, if one is talking about security and hackability, accountability and tracability cannot be discounted. Using pserver eliminates any chances of accountability
Hmmm - I suspect my question was misunderstood, so I shall ask it differently. If I edit the file CVS/Root for a given working directory, are there any other dependencies to be aware of, or is this j