Please send letters via email to email@example.com.
I received several messages regarding Ed Schaefer's
A Menu-Driven Interface to Sybase" in the July
issue - all pointing out
a mistaken reference to the sticky bit. Here are two
letters that set
the matter straight. Thanks to everyone else who wrote
in. - AA
I would like to make a correction to a short article
in your July 1996
issue, p. 52. In the box titled: "The Sticky Bit
and Sybaccess," the
bits in question are NOT called "sticky bits"...
they are called the
"set-user-ID-bit" and the "set-group-ID-bit,"
respectively. The "sticky
bit" is the last bit in that set and when it is
set, it appears as a "t"
in the last column of the permissions.
Originally used to force the storage of frequently used
local memory or swap (make them "stick"),
it has lately been used on
directories with 777 permissions (like /tmp) to keep
other people from
deleting files they do not own. In fact, having the
"sticky bit" set on
/tmp is a security requirement of mine.
It can be set by this command:
chmod 1777 /tmp
Please tell your writers to keep their nomenclature
Thank you for bringing it to our attention. Here's the
To: Ed Schaefer
I flipped through the latest Sys Admin and saw your
Sybase article. I
don't use this database at all, but I did see the sidebar
"sticky bit," and I have to say that it needs
a bit of revision.
First, it's not the sticky bit you're talking about
here, it's the
setuid/setgid bits. The sticky bit was found in older,
environments (Sys V Rel 2, for instance) that told
the OS to keep a
program loaded in RAM even after the last user was
finished with it.
This way when the next user ran the program, it was
However, suggesting that people write setuid programs
like this is so
unbelievably dangerous that you simply cannot even
suggest this in a
published article. The security implications here are
such that there
are a hundred ways to beat this.
1) $ cd /tmp
$ cp /bin/sh sybaccess
You fix this by putting the full path in the system()
2) $ cd /tmp
$ cp /bin/sh tput
$ PATH=/tmp:$PATH /usr/local/bin/runsybaccess
Now, when tput clear kicks in, it runs my program instead
of yours. I
might have to use a script instead of /bin/sh, but
that's a minor
So, you fix the script and put an explicit $PATH at
the very front of it
to forestall this kind of thing.
3) $ cd /tmp
$ SHELL=/tmp/myprogram /usr/local/bin/runsybaccess
Now, when it forks a shell to run your program, it uses
my shell instead
(not many UNIXs are susceptible to this, but some are).
You fix this so that it does a putenv("SHELL=/bin/sh")
before doing the
4) $ cd /tmp
$ cp /bin/sh usr <- yup, "usr"
$ PATH=/tmp IFS=/ /usr/local/bin/runsybaccess
The shell uses $IFS to break apart its inputs into "words,"
normally it's space+newline+tab. By setting IFS to /,
the command it
runs is "usr" with "local" "bin"
"sybaccess" as arguments. Since it's
looking on my path - even if $TMP is at the end - it
will run my
The difficulties go on and on.
Creating a setuid root front-end is so fraught with
troubles that you
have to be exceedingly skilled at getting it right (say,
like me) to
even do this, and then you must have a very healthy
disbelief in your
I have done a number of setuid front-ends, and none
of them runs as root
for very long. These programs (which are very small
and therefore easy
to verify) do their limited business as root and then
revoke their root
permissions before running the user's program directly.
Then, with the
no-root-permissions the security issues become much
A much better solution to most of these issues is running
id, but that's another topic.
So, be very careful when you suggest to others that
they do this kind
of thing. If you're in an environment with all trusted
users (say, your
office) you can do this knowing that it does not need
to be secure - why
break root when you already have it? But, I am certain
that people will
be burned by this if they don't know the risks.
I should have been more adamant about discouraging the
use of this
possible security hole. You definitely plugged it. I
think I've been
properly chastised on this one, but also by readers
Matthew Cheek, Shel
Randall, and Alex Ostapenko.