Richard Stallman <rms@gnu.org> writes:

> In general, anyone who has access to modify the standard Emacs Lisp
> directories can easily modify some commonly-used file
> and make Emacs do whatever he wants.  I don't think that
> the situation with subdirs.el is really diffrent; 

OK, I don't mean to prolong the discussion, but let me just make sure
you've seen my reasoning wrt why IMO it's more dangerous than a) files
that are not run automatically, and b) singular files like
site-start.el.  

I'm appending it for reference.  It's the same as my responses to Kai,
Gerd, and Dave that you may have already seen.

> I don't
> think this is particularly a problem, or that anything needs to be done.

It's your call.  

In case you change your mind, I have written a package I call
sandbox.el that can run untrusted code with some functions disabled.
I'll prolly post it to gnu.emacs.sources in the next few days.


=====================

[singular files like site-start.el]
> But Emacs will also run site-start.el when it starts up.  Why is
> running subdirs.el less secure than site-start.el?

Because there's only 1 site-start.el, which you can easily examine and
presumably nothing goes there without you putting it in.  OTOH, any
subdirs.el at all in your path will get run at start time.  You have
probably not inspected every package you put in your load-path to see
if it contains subdirs.el.  I didn't even know to do that until I
started playing with subdirs.el

=====================
[files that are not run automatically]
> I'm not sure if this can be fixed by doing something special for
> subdirs.el.  I think the same problem occurs with anything else being
> loaded.  Consider, for example, the case that someone puts a
> cc-mode.el(c) somewhere in your load-patch that contains a
> delete-file.

ISTM there are two important differences:

First, in the subdirs.el case, it triggers as soon as you put a
package in your load-path.  Doing that looks safe, but isn't.  You may
not even know you put it in your load-path.  In the other case, code
doesn't trigger until you actually do something.  Maybe something as
simple as triggering an autoload, but you still have to do something.

Second, in the normal case, usually you'd know pretty much what caused
it: what command from what package.  The word would get out fast.  In
the subdirs.el case, what caused it?  You just started emacs and
something went bad.  There's a built-in mystery.

This is a small difference in functionality but IMO a big difference
in security.