We have some machines that are 'no user-operable parts inside' setups; as part of that, they have no user logins, just root . (Yes, yes, running as root all the time is bad, but on these boxes almost all we'd ever do with a plain login is su to root.)

I'm attuned to all of the regular hazards of this, but today I stumbled over a new one: how long it takes to notice that /var had accidentally wound up mode 0750 (and owned by a group that didn't have hardly anything in it) on a Solaris 2.4 machine.

Of course, root doesn't get permission denied messages, and most of the obvious things were running as root and kept on working. About the only sign was a large collection of files called things like ' mailAAAa00087 ' scribbled in /var/tmp . It turned out that these files were complaints from cron about being unable to run lp cron jobs because it couldn't change to lp 's home directory, and bounce messages talking about ' lp... Can't create output '.

So I looked at lp's home directory, /usr/spool/lp , which looked perfectly fine and I could even cd into it as root. Only when I did ' su lp ' and tried it did I get a 'permission denied' error and started backtracking to discover the /var permissions problem.

Sidebar: so how did it happen?

What I think happened is that someone built a tar file of a /var/named directory they wanted to move around, but instead of tarring up the directory, they cd 'd into the directory and tared up ' . '. Then they moved it to this machine and accidentally untarred it in /var instead of making a /var/named directory and untarring it there. As part of unpacking, tar dutifully set the permissions on all of the files and directories in the tarball, including ' . '.

So the moral is: tarfiles that include . are annoying and dangerous in more than one way.