MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2004

Re: Not backing up directory /tmp



fixed

On Wed, 18 Feb 2004 rob@xxxxxxxxx wrote:

> Anyone see an issue with only backing up directory /tmp, in the ifs, only
> every 8 weeks when doing a dedicated save?
>
> Evidently there are numerous IBM jobs that access that directory and it
> causes them a wee bit of grief when it is locked.  Even if I do SAVACT,
> there would be a lock potential, I believe.

There is no problem as long as you use /tmp the way it was designed to be
used.  /tmp is for temporary files (obviously) that don't need to be saved
- ever.  Typical files in /tmp on a unix system are work files that the
compiler uses as it is compiling, swap files for programs like the Gimp,
and other run-time generated files that apps use and are rebuilt on
startup.  It you have a file that needs to be backed then it should not be
in /tmp.  You can find out more about filesystem layout and intended usage
design by reading the Filesystem Hierarchy Standard at:

http://www.pathname.com/fhs/

I never backup /tmp and following David's advice to clear it out is
probably a pretty good idea.  Unfortunately, because of the worl-writable
nature of /tmp there are some tricks malicious users can do to damage your
system when clearing it.  For example, let's say you use a recursive
delete to remove everything in /tmp (I'll give QSH commands here):

cd /tmp
rm -rf *

Now suppose someone has made a symbolic in /tmp that points to your
important data:

ln -s /home/my/important/data /tmp/maliciouslink

or even:

ln -s /qsys.lib/james.lib /tmp/maliciouslink

which would show up like this:

ls -l
lrwxrwxrwx  1 JAMES  DMSIGROUP                    32 Feb 18 11:46 testlink
-> /qsys.lib/james.lib

(that should all be one line).
Now your recursive delete will wipe out the whole library!  In order to
safely remove everything in /tmp you need a program which uses stat() to
check if the file is a link that points outside of /tmp.  If it is, you
only want to delete the link, not the target.

Fortunately modern rm's check for just this scenario.  I did tests on
linux and V5R2 and in both cases rm did not descend into the link and
delete the files.  Here is linux:

lrwxrwxrwx    1 james    users           7 Feb 18 11:54 testlink ->
yngwie/
drwxr-xr-x    2 james    users          64 Feb 18 11:54 yngwie
james@stumpy:/tmp> rm -r testlink
rm: cannot remove `testlink': Not a directory

And here is V5R2:

   drwxrwxrwx  2 JAMES  DMSIGROUP                  4096 Feb 18 11:58
testdir
   lrwxrwxrwx  1 JAMES  DMSIGROUP                     7 Feb 18 11:58
testlink -> testdir
 > rm -r testlink
   $
 > ls -l
   total: 28 kilobytes
   drwxrwxrwx  2 JAMES  DMSIGROUP                  4096 Feb 18 11:58
testdir

So OS/400 doesn't complain like linux, but it also doesn't delete the
directory :)

So why bring this all up if rm works just like we want?  If you write your
own app that deletes files, that app should check that it is deleting the
right file, and not something that a malicious user has linked to.  Plus,
you get an interesting history on unix security :)

James Rich

"As for security, being lectured by Microsoft is like receiving wise
words on the subject of compassion from Stalin."
      -- mormop on lwn.net





Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact