[patch] rc.d/tmp (silly mkdir usage)

[Craig Boston]

On Tue, Aug 02, 2005 at 11:47:19AM -0500, diz at linuxpowered.com wrote:
> Well these notions have nothing todo with the way it works, but they are
> interesting still. I would imagine a dir could be linked too if somebody
> managed to insert a rc.d script in that was ordered sufficiently early
> enough to do the evil tasks you are thinking about. Even if mktemp(1) were
> available at this stage, I wouldn't use it here.

A link could also be left over from before the boot. rc.d/tmp runs
before cleartmp.

> Let me be clear about this, the ONLY reason mkdir is used here is
> because touch is under /usr somewhere which isn't even mounted at this
> point (assuming /usr is mounted seperatly, as is the case on nfs
> diskless systems).

No, touch has different behavior than mkdir.  Whether it was done
intentionally or just happens to be the case because /usr is not
available, mkdir is the most secure and robust way to go, because it
covers all of the cases:

1) /tmp/.diskless doesn't exist
-> A directory .diskless is created, which is then removed

2) /tmp/.diskless is a link to a file
-> mkdir fails because "File exists"

3) /tmp/.diskless is a link to a directory
-> mkdir succeeds but does nothing because -p was specified.  The link
is then removed.

4) /tmp/.diskless is a link to a nonexistent path or name
-> mkdir fails (even with -p) because it can't follow the link: "No such
file or directory"

5) /tmp/.diskless exists and is a file
-> mkdir fails: "File exists"

6) /tmp/.diskless exists and is a directory
-> mkdir succeeds.  Later, /tmp/.diskless is removed _only_ if it is
empty.

Even though touch doesn't change file contents, it could potentially be
abused to change the timestamp on an arbitrary file if a link were left
in /tmp.  The only way to securely use touch or ">" would be to rm -f
/tmp/.diskless first, and that is a potentially destructive operation on
the off chance the administrator created a file called /tmp/.diskless.
It's a very remote chance yes, but why 

Creating a file called that may cause undesired effects such as mounting
an mfs /tmp when you didn't want one, but it won't cause any data loss.

> So we are left with what is availabile in /bin, /sbin, /rescue.
> Therefore mkdir was used as a work-around. What I'm saying is this
> entire thought process is overly-engineered when the shell can simply
> "touch" a file with stdout or stderr. This is indeed the most minor of
> optimizations.

It's not a minor optimization if it changes the semantics of what
happens.  > is very dangerous because it could nuke a random file if a
symlink exists.  Even >> or touch can mess with timestamps or create
files that don't exist, all with the power of root.

Craig