"Ralph A. Mack" <[EMAIL PROTECTED]> 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 like: {$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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs