On Tue, Aug 02, 2005 at 11:47:19AM -0500, [EMAIL PROTECTED] 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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"