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

[Brooks Davis]

On Tue, Aug 02, 2005 at 11:47:19AM -0500, diz at linuxpowered.com wrote:
> > 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.

No, mkdir won't act through the link so it's the best option here:

$ rm nonexistant
$ ls nonexistant
ls: nonexistant: No such file or directory
$ ln -s nonexistant n1
$ mkdir n1
mkdir: n1: File exists
$ ls nonexistant
ls: nonexistant: No such file or directory
$ > n1
$ ls n1
n1
$ ls nonexistant
nonexistant
$ echo foobar >> nonexistant
$ cat nonexistant
foobar
$ > n1
$ cat nonexistant
$ mkdir n1
mkdir: n1: File exists
$

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

Nope.

$ rm nonexistant
$ touch n1
$ ls nonexistant
nonexistant

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050802/62796d19/attachment.bin