On Mon, Apr 03, 2000 at 07:13:44PM +0200, Gerhard Sittig wrote:
> On Tue, Apr 04, 2000 at 13:50 +0300, Marius Oancea wrote:
> > Hello cvs expoerts,
> > If I want to use cvs from my workstation ( and here I am root )
> > how can I commit then changes to the server? If I am a normal
> > user ... no problem, but if I'm root => error: cannot commit as
> > root.
This is a bug in older versions of CVS (pre 1.10, I think, but I'm not
really sure when the patch for it was integrated. It lingered a while
after I submitted it.) The code checks whether you are root before
storing data, in order to have a good name to put in the log. The bug
is that it also checks this on the CLIENT side when doing
client/server CVS.
> There's something wrong in your enterprise. Go and read some
> basic doc about how to deal with priviledges! And don't tell
> your other team members to ask the same question, please :>
There is something wrong in your mind. Go and think some basic
thoughts about there being *varying external factors* in the world!
And do tell your other team members to do the same, please :>
Seriously: There are cases where using CVS as root makes very good
sense. For instance, at my employer, there are basically four roles
we have for machines where it might be relevant to run CVS:
1. Workstation for a developer
2. Development test box for one of our own systems
3. Production box for one of our own systems
4. Development test box for the OSen we run
Our own systems generally take over the box, and run as a myriad of user
ids at the same time (to manage privilege properly).
For role 1, it makes sense to run CVS exclusively as a user.
For role 2, it doesn't matter if the box is trashed, most commands must be
run as root anyway, and the convenience of running with just a root account
outweights any percieved security gain. Box restoration is reasonably fast.
For role 3, just about everything done needs to be done as root; we
occasionally do a minor bugfix on a production box and commit it from
there (extremely constrained by the type of bug, of course.) Having
to change to another user account and chaning file ownerships just to
do this is just an extra hassle and an extra risk.
For role 4, the boxes are also generally trashable (it takes less than
one minute of human time and less than 8 minutes of machine time to
restore a trashed box), and working as root when you are doing kernel
hacking is much more convenient (especially when you get into a
test/boot cycle.)
We don't employ clueless people. In the four years we've worked like
this, we've had one case of a box getting properly trashed (by
software during root work), and that was due to a bug in a script
interacting with a bug in the OS to trash a disk. As the script was
supposed to be labelling disks anyway, it wouldn't have been different
if done as a user - the user would have had to have access to do the
damage anyway.
There are some very, very slight security issues WRT breakins with
this - but they are limited to trusting the CVS server to not be
broken into and come up with an exploit for remote CVS. We see this
risk as small enough to be tolerable; if we get a breakin in the CVS
server, we have larger problems, anyway, as that would herald a
breakin either through plain ssh, or on a developer workstation - and
all our developers do occassional root work on all servers that access
the CVS repository.
Eivind.
