Re: Unix * weirdness

[ant () NOTATLA DEMON CO UK (Antonomasia)]

Blue Boar <BlueBoar () THIEVCO COM>:

> # rm -R *

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

Yes.

> # unlink -proc

Other options are
rm -- -proc
rm ./-proc
find . -name -proc -ok rm {} \;

> 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/*

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

mkdir '/tmp/ etc'
If this is being run from the / directory it looks like trouble.

> For example, can I get a file with spaces in it?  How about
> the | (vertical bar) character?  How about a ; ?

Doesn't help much.  The shell expands the filenames as arguments to
the command, not as fresh commands.

[ant@notatla bb]$ touch 'a | w'
[ant@notatla bb]$ ls *
a | w

Unless an "eval" is brought into it.  Or "xargs" or something.
eval ls *
(in above context pipes to "w")

touch ./-l
date > A
df > B
echo * | xargs wc
(runs "wc -l" on A and B)

Some of the most obvious problems with filenames show up in the like
of (in root's cron)
    find / -type f -name core +mtime 7 -print | xargs rm
which rapidly falls victim to file and directory names with whitespace in.

This can be done less stupidly as
    find / -type f -name core +mtime 7 -exec rm {} \;
but is still vulnerable to races.  You can create a deep nest of directories
with a core file at the bottom and move and link to something else at a
critical moment.

Good ways to remove old files are programs that only change directory step
by step and only remover from the CWD. (e.g. Red Hat's tmpwatch)
Also I've seen chroot recommended for this.  OpenBSD (2.5) has another
predicate for find(1) called from /etc/daily as

cd /tmp  && {
find -x . -name 'ssh-*' -prune -o -type f -atime +3 -execdir rm -f -- {} \;
}

To give shell programmers stronger shoes I added some extra tests to the pdksh
shell.  (unpublished code - might possibly appear on my employer's site)
These do the following 3 things in omitting filename expansions that might be
iffy and in refusing to execute iffy files.

set -o gnw
       glob no whitespace

set -o gnlh
       glob no leading hyphens

set -A tuid root bin ant ...[list of usernames or UIDs]
       Now the shell will only exec or source files that are writable only
       by the accounts defined here as trusted.  This includes the directories
       and all ancestors back to the root.  Here "tuid" is a special
       array-variable name used for this purpose when it exists at all.
       You get a permission denied message when trying to run a 777 script
       for example.

--
##############################################################
# Antonomasia   ant () notatla demon co uk                      #
# See http://www.notatla.demon.co.uk/                        #
##############################################################