[NTLUG:Discuss] Executable Content Considered Harmful
Richard Cobbe
cobbe at directlink.net
Sun May 7 14:12:04 CDT 2000
Lo, on Sunday, 7 May, 2000, Christopher Browne did write:
> On Sun, 07 May 2000 10:38:08 CDT, the world broke into rejoicing as
> Richard Cobbe <cobbe at directlink.net> said:
> > Lo, on Friday, 5 May, 2000, Christopher Browne did write:
> > > 2. Emacs editors (GNU Emacs and XEmacs) both provide the ability to
> > > attach "variables," executable by the editor, to documents.
> > >
> > > This is quite useful if you want to, say, use a customized
> > > electric-C mode for editing programs. When you load a source code
> > > file into the editor, it provides instructions to the editor as to
> > > what indentation policy to apply and such.
> > >
> > > This is fairly well-documented as providing a "hole." If you bring
> > > in files from just anywhere, you should _not_ set up Emacs to
> > > automatically evaluate such variables, as there is the risk of
> > > someone dropping in nefarious code.
> >
> > I'm thinking I should probably lock this down, since I use emacs almost
> > exclusively, even as root.... How does one disable this feature? And
> > does disabling this also break the -*- foo -*- bit to throw the buffer into
> > foo-mode?
>
> Nope; if you don't *know* that you've activated (enable-local-eval), then
> you probably haven't. Look for it in your .emacs file; I expect it's not
> set.
Well, based on your pointer, I dug through the emacs docs. (The following
is for FSF emacs 20.5, as included with RH6.2; other variants may differ.)
The docs aren't completely clear on the various settings which affect this
behavior, but this is what I've discovered.
1) enable-local-eval is a variable, rather than a function or macro. By
default, it's set to 'maybe. This (well, anything besides t and nil)
prompts the user before following the eval: local pseudo-variable.
However, other variable settings (like, say, fill-column) are still
processed.
2) This is probably what you want. Due to the way emacs processes the
local variables section, the only way to put arbitrary code in like this
and have it evaluated (rather than treated as a literal) is by using the
eval: pseudo-variable. If we assume an intelligent user, this is the
best solution, I think. (Of course, they're using emacs, so they're
intelligent by definition! <grin>)
3) The help for enable-local-eval claims that
The command M-x normal-mode always obeys local-variables lists
and ignores this variable.
which doesn't appear to match reality. I invoked normal-mode in a file
with an eval pseudo-var, and it still prompted me before execution.
4) The variable enable-local-variables controls the entire section;
standard t-yes, nil-no, else prompt. Default, this is t. Setting this
to nil ignored the entire section in a small test file. If this is nil,
it also ignores the -*- scheme -*- line initially.
5) If enable-local-variables is t and local-enable-local-variables is nil,
then the local variables section will be ignored, but the -*- scheme -*-
line will be processed. I haven't tried it, but it looks as though it
only processes mode specifications in the -*- line, not additional
variable settings. If enable-local-variables is nil,
local-enable-local-variables is irrelevant.
Richard
More information about the Discuss
mailing list