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: 29 Dec 90 01:59:02 GMT References: <1990Dec25.032451.25017@gpu.utcs.utoronto.ca> <1990Dec28.234940.24202@odin.diku.dk> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 30 In-Reply-To: thorinn@diku.dk's message of 28 Dec 90 23:49:40 GMT 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@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD