[Top][All Lists]

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


From: Anthony Shipman
Subject: Re: "BADROOT"
Date: Fri, 5 Jul 2002 00:59:57 +1000
User-agent: Mutt/

On Wed, Jul 03, 2002 at 02:45:29PM -0400, Larry Jones wrote:
> Anthony Shipman writes:
> > 
> > It seems the only purpose of the restriction is to prevent the user name
> > in the log message being "root".
> Exactly.  Since "root" is usually a shared account, if the log message
> just says "root" you won't know which real person made the changes. 
> > But in subr.c the getcaller() function
> > will read LOGNAME or USER which I can set to control the name in the
> > log file, if I care.
> getcaller() only reads $LOGNAME or $USER if getlogin() fails, which it
> shouldn't ever do, provided you've actually logged in at some point.

I have a local version with CVS_BADROOT not defined. I set LOGNAME and
its value appears in the log file. This is on linux (gcc 2.2.5). It appears
that getlogin() takes notice of LOGNAME.


> > So how about getting rid of this restriction?  As root, I would like to
> > maintain system configuration files/logs with cvs.
> If you want to allow root to commit, just don't define CVS_BADROOT in
> options.h. 

Easy for you to say. Like I think most people, cvs is installed from
an RPM.  Unpacking and patching the source through a source RPM is a
non-trivial exercise.

I think it's a bit obnoxious of the program to enforce a policy like
this which is really only an advisory thing. It's not preventing the
user making a real mistake.

How about have getcaller() give LOGNAME or USER precedence over
getlogin().  Then if the resulting name is "root" it can refuse to
proceed, warning the user to set LOGNAME.

reply via email to

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