[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs commit as root

From: Harry Putnam
Subject: Re: cvs commit as root
Date: Mon, 10 Dec 2001 08:19:47 -0800
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i586-pc-linux-gnu)

"Ralph A. Mack" <address@hidden> writes:


> Keeping a layer of makefile/script between your source control system
> and your deployment areas gives you a greater control of file system
> attributes of deployed files. If you are concerned about security you
> may want this layer in place, as there are some files (e.g.
> /etc/profile) that, in order to be used on a day-to-day basis, need
> different permissions than you would willingly place on other files
> like, say, /etc/shadow.

Some things I don't put in cvs.  /etc/passwd /etc/shadow are amongst
them.  Those are not config files in some sense.  And not likely to
need version control.  I do have a system in place that diffs thoses
on a regular basis for security reasons.  And run tripwire as well.

This layer you speak of.  I don't really get the big picture I think.
Is there documentation about this kind of setup?  Especially as it
pertains to cvs?  I get the feeling people are describing something

{$CVSROOT} <=>interplay1 <=> {checked out module} <=> inerplay2 {system}
and some kind of makefile/scripting setup that automates interplay1
and interplay2.

The checked out module being the buffer you speak of.

> There is always a continuum between convenience and security that any
> system admin needs to weigh. I won't intrude on your prerogative with
> arguments or suggestions in this regard beyond thinking about the
> hassles involved if a third party used your system as a staging platform
> for an attack on somebody with something valuable to lose and the
> habit of pushing their weight around.

It seems unlikely that my cvs setup would be a target of something
like that.  The general system might, but the cvs side of it wouldn't
offer anything very attractive.  To keep my general system protected
from those kind of intruders, I live behind a hardware firewall that
is probably sufficient for the amatuer hackers.  And nothing is really
sufficient for a dedicated serious hacker.  In that light I thought to
keep cvsroot under root protection would be a deterant only.

Lets say, in a lax moment with firewall down or the like a script
kiddy gets in.  Seems it would be a good thing if cvsroot was owner
group root root.  Is that mistaken? So at least until Mr. Kiddie got
root it would be safe.  It would not present a way to alter root owned
files as a user.

More likely would be the event that me or my family do something
unintended.  And again it seems having cvs under root protection would
be a good thing in that case.  Having basic config files that are not
root protected would increase liability in that case.


> If makefiles make you uncomfortable, start out with a few simple shell
> scripts and learn make later. All make really gives you over a
> well-written shell script is convenience (all activity is rule-based)
> and run-time efficiency (since it inherently checks file dates before
> doing anything).

The makefiles syntax threw me yes, but I'm really not a stranger to
shell scripting.  Using ksh, sh and bash, I've probably written well
over 100 homeboy scripts, some of them semi complicated. Not claiming
any skill at this, just that I am familiar with basic shell scripting,
still that makefile stuff looks intimidating to me.  he he.

I'll admit, I'd rather set my hair on fire than try to read a csh
script though, and would contemplate suicide sooner than try to write one.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]