Bug 403481 - /etc/vimrc needlessly hardwires path to /usr/bin/cscope
/etc/vimrc needlessly hardwires path to /usr/bin/cscope
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vim (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Karsten Hopp
Depends On:
  Show dependency treegraph
Reported: 2007-11-28 15:39 EST by Adam Stokes
Modified: 2010-10-22 16:49 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-14 05:19:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
remove bin path to cscope (256 bytes, patch)
2007-11-28 15:39 EST, Adam Stokes
no flags Details | Diff

  None (edit)
Description Adam Stokes 2007-11-28 15:39:54 EST
Description of problem:
/etc/vimrc needlessly hardwires path to /usr/bin/cscope.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Engineers use own /router/bin/cscope which writes a subtly different cscope.out.
If an engineer then runs vi/vim and has one of these cscope.out files in their
current working directory, they will get the following error:

[user@server ios]$ vi
Error detected while processing /etc/vimrc:
line   32:
E609: Cscope error: /usr/bin/cscope: cannot read old index format; use -U option
to force database to rebuild
Hit ENTER or type command to continue

Even though they have specified the non-standard cscope binary via their path.
Actual results:
[user@server ios]$ vi
Error detected while processing /etc/vimrc:
line   32:
E609: Cscope error: /usr/bin/cscope: cannot read old index format; use -U option
to force database to rebuild
Hit ENTER or type command to continue

Expected results:
Run alternate cscope

Additional info:
Comment 1 Adam Stokes 2007-11-28 15:39:54 EST
Created attachment 271751 [details]
remove bin path to cscope
Comment 4 Karsten Hopp 2008-01-14 05:19:13 EST
I'd rather not use binaries without a full path in /etc/vimrc for security 
A better solution to your problem would be to overwrite the csprg variable in 
the users $HOME/.vimrc.
Comment 5 Joshua Jensen 2008-01-14 11:32:18 EST
I find this nearly laughable.  Presumably the user opened a terminal window, and
typed "vi".  They probably typed a lot of other commands on the command line too.
When they start vi manually, you don't really type "/bin/vi", do you?
Same for cscope... if you were to start it from the command line... do you
consider it a security risk if you just type "cscope"... as opposed to

We have a way, in Unix, to determine what should be run, and where it should be
run from.  Its called $PATH.  It is standard and accepted practice for
everything else... but not for vimrc?

Rolling out a .vimrc for 6000+ existing users, many of which already have their
own highly customized .vimrc, is a huge task.  That is what we would have to do
to work around Red Hat's fear of $PATH.
Comment 6 Josh Bressers 2008-01-14 16:44:38 EST
Yes this would be considered a security risk.

The contents of a users $PATH are uncontrolled and should not be trusted in this
respect.  One of the goals one must strive for in the context of security is to
maintain a certain level of trust between the application and the user.  The
assumption should always be made that the user has done (or will do) something
silly.  Good security decisions such as this will help mitigate the potential
loss of computing resources.

The individual administering a given system is of course free to determine what
their level of comfort is.  Nothing will stop you from distributing a custom
vimrc file to your systems.  RPM has mechanisms in place to preserve any vimrc
changes across vim updates.

As far as good security practices go, the default should be conservative, which
this is.

Note You need to log in before you can comment on or make changes to this bug.