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

[Barry Shein]

Sean Fagan pointed out two errors in my description of how the sticky
bit worked at some point in time and on some system somewhere.

1. I said that it saved time looking up the path of the executable.
This of course is absurd.

The path always has to be resolved and the fact that it is already in
swap or memory due to its stickiness is noticed much later (by
comparing inode/dev values with those already available, it doesn't
matter if it's due to stickiness or that someone else is already
executing the file, at least not at this level of description.)

The major speedup is/was/might-have-been due to the kernel being able
to pull an executable image from swap faster than from the file system
(no chasing of indirect blocks and so forth), and the possibility that
it was still in memory which was faster still.

The more recent file systems which cause text to page in place make
this consideration more or less obsolete.

2. I said that too many sticky files could cause a process table
overflow. I meant a text table overflow.

Well, you get what you pay for...have a nice day.
-- 
        -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