From: Olaf Lenz (
Date: Fri Feb 21 2014 - 02:46:04 CST

Hi John!

2014-02-19 16:16 GMT+01:00 John Stone <>:

> I would be happy to add an environment variable to customize this
> behavior so it can be disabled in your case.

I think that would be good to have, and I would recommend to disable the
behavior by default.

IMHO, if you are being attacked by someone with
> access to a shared filesystem where you do your VMD work,
> you've likely already lost the battle. There are a seemingly
> endless stream of local root exploits that an attacker could use
> to gain superuser privilege, and if they get that far it is a
> short step for them to put files anywhere they want. I don't
> consider VMD (or similar programs) to be security-relevant in any
> real sense.

Of course this problem won't easily give you root access, as I hope that
nobody will ever run VMD as root. To do that, a malicious user would have
to use the .vmdrc to install a key logger for another user or something
like that.

However, it can easily create problems between users, and it allows for
really scary things in big multi user systems, in particular when you have
very different users on the system.
For example, our system hosts both scientists as well as students, and in
both groups there is a wide variety of Unix knowledge. If any of the
students wants to do something nasty (say, after a botched exam), he would
just have to put a .vmdrc with some nasty code in /tmp, or maybe in his
home dir, and ask the tutor to have a look at the simulation trajectory
that he has stored there.

A further complication comes from the fact that the file is hidden. I think
most people at least use 'ls' before they do anything in a foreign
directory. However, in the case of VMD, that would not even help. So I
think the least you can do is to call the file in the current directory
"vmdrc" instead of ".vmdrc".


Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607