phil@utecfa.UUCP (Philip Poulos) (04/16/84)
Now that I know we are not the only ones to have this "feature" of ex/vi
I should point out the obvious problems.
BUG: Any vi command will be executed as soon as you run ex/vi on a file
that contains a string that matches the following conditions
- the string starts with "vi:" or "ex:"
- the string ends with ":"
- the string appears in the first 5 or last 5 lines of the file
EXAMPLE: As seen in my original mail the string vi:q!: results in quitting
the editor, before you even get in.
vi:!rm *: Will remove all your files while you are waiting for the
vi prompt.
There are, of course, better examples... picture the super user
editting a source file from the net that has vi:!rm -rf /: hidden
in the file, or perhaps vi:!kill 1: The list is endless.
I found this by accident (what else is in vi?)
We have a login name in the password file
that ends with "vi", so the string "vi:encryptedstuff:" caused ex to
burp mildly. Further investigation led to the discovery of the bug.
So everybody that has this ex/vi version (4.2 bsd, maybe others) you better
fix it fast. Otherwise you leave yourself open to an attack of KILLER MAIL.
FIX:
in ex/ex_io.c 2 pieces of code should be removed.
1: remove the routine checkmodeline(), it starts at line ~850
2: In rop2() remove the call to checkmodeline()
the entire for loop should go, it looks like
for(a=first; a<=lost; a++) {
if(a == first+5 && last-first >10)
a = last - 4;
getline(*a);
checkmodeline(linebuf);
}
Phil (I'll try vi next year) Poulosmark@cbosgd.UUCP (Mark Horton) (04/17/84)
Why do you assume this is a bug? It was put in as a feature at the request of some users, so that vi "set" commands could automatically be run when certain files are entered. EMACS has a similar feature. The only problems are (1) it isn't documented (an oversight on my part), and (2) you seem to have found a security problem. It would indeed be possible to take the feature out (and since most of you didn't know it was there, you'd never notice that it was gone), but it makes more sense to set a flag while checkmodeline is in operation, and refuse to do any ! or sh commands with this flag set. The mode line feature was put into vi version 3.7, and is still in, so it's in 4.2BSD and System V.
jpl@allegra.UUCP (John P. Linderman) (04/18/84)
Things are even worse than Philip Poulos let on. Here is the routine he
suggested removing (a suggestion I am implementing as fast as `make' can run):
checkmodeline(line)
char *line;
{
char *beg, *end;
char cmdbuf[1024];
char *index(), *rindex();
beg = index(line, ':');
if (beg == NULL)
return;
if (beg[-2] != 'e' && beg[-2] != 'v') return;
if (beg[-1] != 'x' && beg[-1] != 'i') return;
strncpy(cmdbuf, beg+1, sizeof cmdbuf);
end = rindex(cmdbuf, ':');
if (end == NULL)
return;
*end = 0;
globp = cmdbuf;
commands(1, 1);
}
Because of the way it checks for "ex:" or "vi:", it will also accept
"ei:" or "vx:". Because of the way it fails to check that the ':'
is at least 2 characters into the line, it might also accept "x:",
"i:" or just ":", depending on the state of the chars in front of
the linebuf array. If you are willing to live with this "feature",
you probably won't care about accepting bogus keywords, but you can
sleep a little easier if you do something like
if ((beg == NULL) || (beg < (line + 2)))
return;
if (strncmp(beg-2, "ex", 2) && strncmp(beg-2, "vi", 2))
return;
John P. Linderman Department of Fun Software allegra!jplprabhaka@ucbvax.UUCP (Aloke Prabhakar) (04/18/84)
Sorry guys, you really cannot call that a bug. It is a documented *feature*. (really) There are people here who actually use it. If your afraid of booby-traps, there`s always cat/more. Aloke Prabhakar wouldnt-it-be-funny: ...moskvax!kremvax!mcvax!decvax!ucbvax!prabhaka USENET: ...ucbvax!prabhaka ARPANET: prabhaka%ucbarpa@Berkeley
scw@cepu.UUCP (04/18/84)
This bug doesn't seem to be in the 2.8 BSD version of ex/vi (version 2.13).
--
Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp: { {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw
ARPA: cepu!scw@ucla-locus location: N 34 06'37" W 118 25'43"alan@allegra.UUCP (Alan S. Driscoll) (04/18/84)
> ... it makes more sense to set a flag while checkmodeline is in > operation, and refuse to do any ! or sh commands with this flag > set. Ah, the Berkeley mentality at work! How do you fix a misfeature? By throwing another feature on top of it, of course... -- Alan S. Driscoll AT&T Bell Laboratories
jdb@mordor.UUCP (04/18/84)
I'm not convinced that this "feature" is necessary (or even desirable).
If it is going to be implemented anyway then please make it optional.
Here's my proposal:
A "set" option ("modeline", "ml") would be used to enable processing
of the "vi:" or "ex:" information. The default would be "nomodeline".
Users who wanted this feature could put the appropriate "set" command
into their ".exrc" files (or EXINIT environment variables).
I, for one, do not want this "feature"; however, at least one local
user does. I plan to fix "vi" to work as described above.
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758
UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdbrcd@opus.UUCP (Dick Dunn) (04/18/84)
Mark Horton, on "vi" taking commands from its input file: >Why do you assume this is a bug? It was put in as a feature at the >request of some users, so that vi "set" commands could automatically >be run when certain files are entered... I suspect that if response in unix-wizards is any indication, there are more people who think that this is bad than people who want it. The slip in not documenting it means that many users may have not had a chance to express opinions about it--until now, with many of them (myself included) becoming paranoid about using "vi". There is a fairly basic principle about text editors being ignored in this feature: A text editor is a tool for manipulating text files. The fewer assumptions the editor makes about its data, the more general its applicability. We mostly accept the idea that editors work with ASCII and are therefore somewhat ungracious in handling characters with the top bit set (but please, that's a different discussion), and we tend to expect line boundaries now and then (another different discussion), BUT most of the text we manipulate satisfies these conditions. If you put editor commands in the file to be edited, you've said that the file is, in part, not data but a command script for the editor. What other programs can process that file? They have to understand or ignore the editor commands. You've got a fundamentally different type of file if it has editor commands embedded. Moreover, consider what happens if you get a gonzo command string in a file that you were editing! Now you've got to figure out what happened and use ANOTHER EDITOR to fix the mess. If you MUST spend still more of our dwindling memory (and no, it's NOT all virtual anyway) on such a feature, isolate it somehow so that the general users of vi don't have to worry about stepping in it every time they edit a file. For example, invoke the editor with a different name (as in the e/ex dodge) or add a flag to the command line; just don't make it the default. -- ...Are you making this up as you go along? Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303) 444-5710 x3086
rjhurdal@watmath.UUCP (David Canzi) (04/18/84)
Yes, you can call it a feature if you want, since it was obviously deliberately put there. But, if the first five or the last five lines of /etc/passwd contain a userid or encrypted password ending in "vi", "ex", "vx", or "ei", then using "vipw" becomes a risky business. This feature is a trap waiting to spring on the unwary, and such features are unwelcome in any programming language, operating system, or text editor. It obviously serves a purpose, but some safer way ought to be found to accomplish this purpose.
smk@axiom.UUCP (Steven M. Kramer) (04/19/84)
I would hope that the checklinemode flag would be off by default
and only activated thru EXINIT or .exrc. It's a scary default option.
So all you 4.2 sites out there, quickly type `halt' and bring up 4.1
again. If you think I'm serious, I'm not. Rather, I'm ...
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)thomson@uthub.UUCP (Brian Thomson) (04/19/84)
Okay, it should be classified as a bad idea rather than a bug, since
it was deliberate. There appears to be another questionable feature
in vi 3.7, and I quote from /usr/src/ucb/ex/ex.news:
If there is a file .exrc in the current directory, it will be
sourced when you enter vi, after your EXINIT or ~/.exrc.
I can see users leaving .exrc files in every directory they can write,
hoping that the superuser will trip over one someday. We may can
this bad idea as well.
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!uthub!thomsonchenr@tilt.UUCP (Raymond Chen ) (04/20/84)
<wheeee.... isn't this fun>
I don't know about people out there, but on the 4.2 system I can get
to, there is file in the ex/ directory called ex.new (or ex.news) that
*does* contain a report on the "feature" as well as other changes made
in between versions 3.7 and 3.6. Of course, I don't know if that
comes with to you without source license, but I suspect that it would.
Agreed, it's not the best place to put documentation, since nobody but
us ex hackers even look in the directory, but it's there.
--
From the Random Fingers of --
Ray Chen
{allegra | ihnp4 | mhuxi}!princeton!down!tilt!chenr
"It's amazing what a thousand monkeys and a few typewriters can accomplish..."richard@sequent.UUCP (04/20/84)
Maybe it would be enlightening to hear if someone in netland has ever used this "bug"/"feature' in any sense. I admit it might come in handy, but can't imagine where... ___________________________________________________________________________ The preceding should not to be construed as the statement or opinion of the employers or associates of the author. It is solely the belief... from the confused and bleeding fingertips of ...!sequent!richard
simpers@ucbvax.UUCP (Scott Simpers) (04/22/84)
(1) vi/ex reading commands from its source files. I reluctantly have to agree that this is a bad idea. I can see where it would be very useful, but I think the dangers outway the advantages. (2) vi/ex reading .exrc from current directory and home directory: This one IS a good idea. It can take the place of some of the things that (1) was supposed to do. Different types of files often require different configurations. For example, 'autoindent' is very useful when writing a program, but a pain in the rear when typing text. I like the idea of vi being automatically reconfigured for these different tasks. Scott ...!ucbvax!simpers
alan@allegra.UUCP (Alan S. Driscoll) (04/22/84)
> (1) vi/ex reading commands from its source files. I reluctantly have to > agree that this is a bad idea. I can see where it would be very > useful, but I think the dangers outway the advantages. > (2) vi/ex reading .exrc from current directory and home directory: > This one IS a good idea. It can take the place of some of the > things that (1) was supposed to do. Different types of files > often require different configurations. For example, > 'autoindent' is very useful when writing a program, but a pain in > the rear when typing text. I like the idea of vi being > automatically reconfigured for these different tasks. What if you have different sorts of files in the same directory? Don't you really want your editor's configuration determined by the extension of the file you're editing? That way, you get autoindent on '.c' files, etc. Gosling's Emacs has such a facility. -- Alan S. Driscoll AT&T Bell Laboratories
agb@ucbvax.UUCP (Alexander G. Burchell) (04/23/84)
The gentleman asked if anyone had ever used this feature (YES! It is a feature, by definition if for no other reason). I certainly have; I used to use it every day. Vis: ; Random lisp program ; vi: set lisp : (defun foo (bar) (baz (bletch etc))) or: .\" Random nroff file .\" vi: se noai : BTW, my EXINIT is "set ai sm sw=8 terse report=1", and I find autoindent to be not useful while writing text... I agree that there should be a "modeline" option, default unset. But there *is* a better solution, which I employ now. Use EMACS. -- Alexander Burchell [agb@ucbarpa] [ucbvax!agb]
crl@pur-phy.UUCP (Charles LaBrec) (04/26/84)
The two "features" added to vi/ex sounds like an attempt to give it a limited flavor of EMACS "modes"--something that all of us EMACS users know and love. Charles LaBrec UUCP: pur-ee!Physics:crl, purdue!Physics:crl INTERNET: crl @ pur-phy.UUCP
gbergman@ucbtopaz.CC.Berkeley.ARPA (05/01/84)
Subject: "MAJOR BUG" (vi modeline) -- a safe & powerful alternative
Newsgroups: net.unix-wizards,net.bugs
Convenient though it may be to have a command executed
automatically on entering a file with the editor, it is still
more useful to be able to keep command lines in the
file and execute any of them ad lib.
Given a line of the file, the way to execute it as a bottom-line
command is to yank it to a named buffer, e.g.
"ayy
and then give the bottom-line command that executes the contents of
that buffer, in this case
:@a
I have an item in my EXINIT that makes the single keystroke
control-O do this for me. I will give it twice below, once exactly
as it appears in my EXINIT, and once with the two control-characters
shown explicitly as ^+Letter, for those of you seeing this through
``more'' etc.:
map "ayy:@a
explicitly: map ^O "ayy:@a^M
In addition to allowing you to keep commands in files for repeated
use, it makes it possible to carefully edit a command before executing
it, make a modification if the first version did not do what you meant
it to, etc.. It was actually for such editing capability that I set it
up, and the practice of storing commands for reuse developed after.
The above mapped key can be preceded by a count. E.g. 3^O will
execute the next three lines as bottom-line commands.
Let me note a couple of limitations:
In a bank of commands so executed together, e.g. by 3^O, none
except the last may be a ``global'':
g/pattern/command
If a global appears in nonfinal position, all commands after it are
ignored. (This seems to be a general bug of vi; the same thing happens
if one gives on the bottom-line of vi the command
:source filename
and the file contains a global in nonfinal position. Only in ex mode
does the command :source behave properly. Modeline also seems to
be confused by global commands, by the way.) On the other
hand, I regularly execute banks of many mappings together with no
trouble, as well as things like:
10,-w !nroff|col|lpr -h
x
or
-r !date
+,$-w !mail NAME
Banks of several substitute commands sometimes give trouble; messages
like ``extra characters after substitute command''.
Also note that since we are in vi, not ex, the ex commands i, a,
and c cannot be used. (However, in place of a one can use, say
s/$/^Mline1^Mline2^Metc./
with ^M's entered as ^V-carriage-return, and similar
substitutes for the others, if the resulting command isn't too long.)
Commands executed in this way (in fact, any commands
given by mappings, @x macros, etc.) cannot execute a ``yank'' (or a
deletion to a named buffer) after any operation that changes the
file. (According to Mark Horton, there is good reason for this if the
yank is to the ``nameless'' buffer; the fact that it affects yanks to
named buffers as well is a bug.) This behavior is somewhat capricious:
I have written one command involving such a yank that works OK for no
reason I understand, and another that does something totally
unrelated to what it ought to.
Sometimes an ``undo'' following a command undoes both it and
some preceding commands!
To avoid accidentally executing a command with serious consequences
(e.g. mailing a half-written letter, which I once did) one can write in
such commands preceded by the escape character ", e.g.
"+,$-w !mail NAME
and delete the " only when ready to use.
Despite its minor drawbacks, this trick has totally transformed
the use of the editor for me! I would be very interested in other
people's reactions.
I have some similar tricks for executing file-lines in
ex mode instead of vi mode (mainly developed when I was on a PDP
and didn't have a version 3.7 editor with its @-macro facility).
I occasionally use them when I want to execute something with
successive global commands; I'll give details if anyone is interested.
They're clumsier than the technique described above; I'd be
interested if one of you could come up with a version that wasn't.
(Those of you here at Berkeley may have seen a version of this
message on msgs, with ^A in place of ^O. I switched to ^O
because of ^A's interfering with function keys on some terminals.
And those of you at UCLA may have seen a version of my Berkeley message,
edited by David Cantor, who silently replaced my ^A with \, and changed
the mapping so that it would delete the original command line, both of
which changes I disagree with, especially the latter.)
I will mention, finally, that I have a large file of editor
bugs, as well as suggestions for possible improvements in the editor,
interspersed with comments and rejoinders by Mark Horton. If
anyone would like a copy, I will send it.
George M. Bergmanchris@umcp-cs.UUCP (05/03/84)
There are a number of bugs (and potential bugs, for anyone making
changes) in ex/vi due to ``11 squishing'' (reusing buffers all over
the place). If you decide to experiment with macros, named buffers,
yanking, and undoing, test it out in a "junk file" first!
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland