== A surprising hazard of running as root all the time

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.~~