Description of problem: /etc/vimrc needlessly hardwires path to /usr/bin/cscope. Version-Release number of selected component (if applicable): 6.3.046-0.40E.7 How reproducible: 100% 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:
Created attachment 271751 [details] remove bin path to cscope
I'd rather not use binaries without a full path in /etc/vimrc for security reasons. A better solution to your problem would be to overwrite the csprg variable in the users $HOME/.vimrc.
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 "/usr/bin/cscope"? 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.
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.