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

[diz at linuxpowered.com]

> On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz at linuxpowered.com wrote:
>> Howdy hackers,
>>
>> I'm sorry for the previous patch, so here is at least one item that
>> really
>> bugs me that isn't obfuscation. In short, I don't see any reason to fork
>> some process to simply "touch" a file (is a filesystem writable) when
>> built-in shell i/o does this:
>>
>> --- /etc/rc.d/tmp.orig  Mon Aug  1 23:20:24 2005
>> +++ /etc/rc.d/tmp       Mon Aug  1 23:22:07 2005
>> @@ -48,8 +48,8 @@
>>  [Nn][Oo])
>>         ;;
>>  *)
>> -       if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then
>> -               rmdir /tmp/.diskless
>> +       if ( > /tmp/.diskless 2> /dev/null); then
>> +               rm /tmp/.diskless
>>         else
>>                 if [ -h /tmp ]; then
>>                         echo "*** /tmp is a symlink to a non-writable
>> area!"
>>
>
> The thing you suggest is bloody insecure. Just imagine some baduser
> doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed.
> I guess this is the reason why directory creation is used instead of
> file creation.

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.

>
> I just wonder why a new shell is forked for this test. Simply
> if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then
> would do the same thing without forking a new shell that only executes
> /bin/mkdir

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

>
> Even we can use
> if [ -d /tmp -a -w /tmp ] ; then
> or (which is equivalent)
> if [ -d /tmp ] && [ -w /tmp ] ; then
> and save external commands (mkdir) execution and directory
> creation/deletion at all.
>