Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: What does SUID, SGID and Sticky bits do on inappropriate files? Message-ID: Date: 25 Dec 90 07:12:20 GMT References: <1990Dec25.032451.25017@gpu.utcs.utoronto.ca> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 91 In-Reply-To: jmason@gpu.utcs.utoronto.ca's message of 25 Dec 90 03:24:51 GMT 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@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD