[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The `risky-local-variable' blacklist
From: |
Davis Herring |
Subject: |
Re: The `risky-local-variable' blacklist |
Date: |
Tue, 31 Aug 2004 15:42:03 -0600 (MDT) |
> Actually, for mode-line variables, the situation is a bit more complex:
> the lack of "risky-local-variable" annotation was not introducing any kind
> of security hole because when we interpret a mode-line-string, we discard
> any "dangerous" element (such as "eval") unless the variable is marked as
> "risky". I.e. either we check its safety via the "risky" annotation or we
> assume it's dangerous and we only use known-safe elements.
>
> So the "risky" annotation was only added in order to enable potentially
> dangerous things like "eval" in that variable.
We may be speaking at cross-purposes, but are you sure about that?
$ emacs -q lvtest #lvtest is attached to this message
M-: java-mode-abbrev-table RET
>> cheese
M-: java-mode-syntax-table RET
>> (((nil)))
Both those variables are set sans prompting with the default security
settings; of course, those variables (and the nonsense values I supply)
are harmless, but other random variables with no `risky' or `safe'
indications might not be.
I realize now that my example about timeclock is silly, because
`timeclock-mode-string' wasn't dangerous before and isn't now, since it
has never been included in `mode-line-format' except as a symbol, and
those are not evaluated twice (so as to execute a form set as its value).
However, this is itself worthy of note: gm, when he applied the
`risky-local-variable' brand, had mis-diagnosed the danger of that
variable. All it takes is for one person (whose code, whether part of
Emacs or not, is used widely) to misdiagnose (or forget to diagnose) a
variable in the other direction, and trouble ensues.
So I believe my original statements about the (potential and extreme)
danger of such things -- and the necessity of improvement in their control
-- stand.
Davis Herring
--
This product is sold by volume, not by mass. If it seems too dense or too
sparse, it means mass-energy conversion has occurred during shipping.
lvtest
Description: Local Variables Test