Next: Dired says, ‘no file on this line’ when I try to do something., Previous: Why does shell mode lose track of the shell’s current directory?, Up: Bugs and problems [Contents][Index]
Any package you install into Emacs can run arbitrary code with the
same privileges as the Emacs process itself. Be aware of this when
you use the package system (e.g. M-x list-packages) with third
party archives. Use only third parties that you can trust!
file-local-variable feature. (Yes, a risk, but easy to
change.)
There is an Emacs feature that allows the setting of local values for variables when editing a file by including specially formatted text near the end of the file. This feature also includes the ability to have arbitrary Emacs Lisp code evaluated when the file is visited. Obviously, there is a potential for Trojan horses to exploit this feature.
Emacs has a list of local variables that are known to be safe to set.
If a file tries to set any variable outside this list, it asks the
user to confirm whether the variables should be set. You can also tell
Emacs whether to allow the evaluation of Emacs Lisp code found at the
bottom of files by setting the variable enable-local-eval.
See File Variables in The GNU Emacs Manual.
Emacs accepts synthetic X events generated by the SendEvent
request as though they were regular events. As a result, if you are
using the trivial host-based authentication, other users who can open X
connections to your X workstation can make your Emacs process do
anything, including run other processes with your privileges.
The only fix for this is to prevent other users from being able to open
X connections. The standard way to prevent this is to use a real
authentication mechanism, such as ‘MIT-MAGIC-COOKIE-1’. If using
the xauth program has any effect, then you are probably using
‘MIT-MAGIC-COOKIE-1’. Your site may be using a superior
authentication method; ask your system administrator.
If real authentication is not a possibility, you may be satisfied by just allowing hosts access for brief intervals while you start your X programs, then removing the access. This reduces the risk somewhat by narrowing the time window when hostile users would have access, but does not eliminate the risk.
On most computers running Unix and X, you enable and disable
access using the xhost command. To allow all hosts access to
your X server, use
xhost +
at the shell prompt, which (on an HP machine, at least) produces the following message:
access control disabled, clients can connect from any host
To deny all hosts access to your X server (except those explicitly allowed by name), use
xhost -
On the test HP computer, this command generated the following message:
access control enabled, only authorized clients can connect