>
> It took me a minute. It's taking the file named -proc and parsing as
> if it was a set of command line options. I guess this makes some
> sense.. I believe the shell just takes all the files and makes them all
> command-line parameters when you use *.
>
> Naturally, I've been thinking about the possibilities... I haven't
> had much time to work out details (got sucked into Y2K weekend
> work) so I wanted to pass this to the list for further explanation.
>
> BTW, I got rid of it with:
>
> # unlink -proc
>
> So, I wonder what other kinds of traps can be laid for the root
> user or cron jobs, etc... For example, here's a line from my
> S05RMTMPFILES in /etc/rc2.d dir, on a Solaris 2.6 machine.
> (Which is where this behavior was noticed):
>
> /usr/bin/rm -rf /tmp/*
The above command would work properly with a file named "-foo" in /tmp. The
shell would simply replace /tmp/* with /tmp/-foo (among other things), which
isn't parsed by getopt(3). There is only a problem here if the script did
something like "cd /tmp && rm -rf *".
>
> So, if I can place an interestingly names file in /tmp
> (and anyone can) can I get interesting things to happen
> when the machine reboots.
>
> For example, can I get a file with spaces in it? How about
> the | (vertical bar) character? How about a ; ?
All of these characters are interpreted BEFORE the glob (*) is expanded, so
they should work just fine. The only exception would be if the programmer
does something dumb like passing the glob to eval.
>
> (Yes, I could test it myself if I had time at the moment.)
>
> Is this a really old "feature" that everyone knows about except me?
I wouldn't call it a "feature"... it's just the way the shell and getopt(3)
interact.
Received on Jan 01 2000
Intro
