What does SUID, SGID and Sticky bits do on inappropriate files?

[Barry Shein]

gak, this has become a mess, hasn't it? They're asking what the sticky
bit does on "inappropriate files", like executable ones...

>	What is the effect of the sticky bit on files which are not
>directories: i.e.
>	
>	- Plain Files
>	- Executable Files

In the first place, this is version dependent (unfortunately, it's
become *very* version dependent since some of these bits have become
free real-estate for implementations to stick their features on as
they don't always have any meaning anyhow.)

Originally the sticky bit meant that an executable's image was to be
saved (usually in swap space) after it exited. The idea was it was
faster to re-start a swap image than pull something in from disk (if
nothing else, it saved you searching the PATH although it also saved
you from having to chase indirect blocks since swap images are
contiguous.)

Thus the name, it "stuck" in swap.

Normally a text image was abandoned when no one was executing it any
longer. If someone came along and re-ran it, it had to be pulled back
into memory.

Short running commands like "ls" would react faster if they could be
kept in swap (note: there were various philosophies and arguments
about what was good to set the sticky bit on.) Since they were short
running, then it was rare (on smallish systems) that there would
always be someone running it, so it constantly had to be read in from
disk.

Making an executable sticky solved that, and noticably sped up startup
on commands like ls.

Today it seems almost silly, but back when it could take a few seconds
or more before ls started printing, and a lot of that was due to
pulling it into memory etc. Depending on system behavior (and how much
swap space you could spare) people might also make editors sticky,
depended on what the chances were that someone would be running it all
the time anyhow (if they were there was no use making it sticky, but
then again there wasn't much harm either IF someone was always running
it.)

It was a "good" way to cause a system to run out of swap space and/or
process slots, however. And the only way to back out was to unset and
reboot the system. Once the kernel decided an executable was sticky it
never looked at the inode again (until it was rebooted.)

Note that you were able to get about the same effect by just starting
a process and blocking it, where possible (e.g. starting up an editor
and pushing to a new shell, and forgetting it, then everyone else on
the system would get quick activation.) For some commands, like ls,
this is hard to do, but it gets the point across, unix shares the code
segments and some of the data segments of processes (hmm, I could
write a few more paragraphs about this, let's leave it at that.)

The sticky bit, to my knowledge, never had any effect on plain files.

On executable files it had the described effect, that was what it was
there for!

The effect on directories came much later (what was the first regular
distribution of a Unix to include this? 4.3 I think, tho there was
something in 4.2 like this) although it was common to hack that sort
of semantic into your own kernel, I believe I saw this on V7 systems
back when they were current. And other interpretations (hmm, what,
caching the directory? stuff like that, roll your own.)

For the other combinations (set[ug]id, text) on special files they're
just undefined and ignored by the kernel. I suppose some utility used
these bits for terminal files, we had a hungry bit at BU which, if set
on your terminal, meant you were looking for someone to have lunch or
dinner with, finger would indicate who had their hungry bit set.

Interestingly, on SunOS 4.x I can't even set the sticky bit on plain
or executable files (thinking it was the utilities ls and/or chmod
fighting with me I wrote a quick hack to do it thru chmod() and read
it back with stat(), no dice, never got set.) I was able to set the
sticky and setid bits on a device file though.

So, I am sure someone, someday, will use those now unused bits to
solve some problem, poorly no doubt...tho hungry was a good use.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs at world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD