bzs@world.std.com (Barry Shein) (12/25/90)
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
rickert@mp.cs.niu.edu (Neil Rickert) (12/25/90)
In article <1990Dec25.032451.25017@gpu.utcs.utoronto.ca> jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes: > Also what are the effects of the Set-User-ID and Set-Group-ID >bits on files which cannot be properly said to be *EXECUTED*? (Though the X >permissions are set) For instance Directories, but also the other types >of special files named above? > Recent versions of 'sendmail' use the suid/sgid bits when mailing to a file. That is, when an alias in your aliases file (or in a user .forward) lists a file name to which mail is to be appended. In that case 'sendmail' uses the owner and/or group of the file while writing. Note that the suid and/or sgid bits must be set, but NO execute bits may be set for this to work. 'sendmail' refuses to mail to a file with any execute bits set. (Observed behavior documented in the source code of sendmail-5.64,5.65) -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
djm@eng.umd.edu (David J. MacKenzie) (12/26/90)
In article <BZS.90Dec25021220@world.std.com> bzs@world.std.com (Barry Shein) writes: > 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. Regular users can't, but the superuser can. egypt# id uid=0(root) gid=1(daemon) groups=1(daemon),10(staff),12(pr-cntl) egypt# cp /dev/null xyzzy egypt# ls -l xyzzy -rw-r--r-- 1 root staff 0 Dec 25 12:53 xyzzy egypt# chmod 1644 xyzzy egypt# ls -l xyzzy -rw-r--r-T 1 root staff 0 Dec 25 12:53 xyzzy egypt# chmod 1755 xyzzy egypt# ls -l xyzzy -rwxr-xr-t 1 root staff 0 Dec 25 12:53 xyzzy -- David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
bzs@world.std.com (Barry Shein) (12/26/90)
From: djm@eng.umd.edu (David J. MacKenzie) [Responding to me] >> 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. > >Regular users can't, but the superuser can. Whoops, you're absolutely right, I stand corrected. Most unix versions restrict setting of the sticky bit to the super user for obvious reasons (making texts sticky could impact system performance in global ways.) -- -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
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/26/90)
As quoted from <1990Dec25.155758.8227@mp.cs.niu.edu> by rickert@mp.cs.niu.edu (Neil Rickert): +--------------- | In article <1990Dec25.032451.25017@gpu.utcs.utoronto.ca> jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes: | > Also what are the effects of the Set-User-ID and Set-Group-ID | >bits on files which cannot be properly said to be *EXECUTED*? (Though the X | >permissions are set) For instance Directories, but also the other types | >of special files named above? | > | Recent versions of 'sendmail' use the suid/sgid bits when mailing to a +--------------- This is also done by System V at/cron to make sure that crontabs and at job files aren't "usurped" by someone else, since chown clears setuid/setgid. This of course is an aspect of System V's permissive chown rules, about which see threads elsewhere (I decline to comment). Some SCO Xenix, SCO "UNIX", and possibly SVR3.2 use setgid on non-executables to indicate that normally cooperative file locking should actually be mandatory. The SCO "UNIX" systems at work do not use g+s on files, however; the command used is "chown +l". SunOS and maybe other Unixes use g+s on a directory to produce sticky gid's: files created in the directory inherit the directory's gid instead of the creating process's egid. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
tr@samadams.princeton.edu (Tom Reingold) (12/28/90)
Here is some more (paraphrased) information from my System V Release 3
manual page for ls(1):
if doing "ls -l" on a file yields
-rwSrwlr-T 1 tr other 10 Dec 27 16:35 file
then
1. The 'S' means the set-uid bit is on but the user-execute bit is
off. This is undefined.
2. The 'l' means the set-gid bit is on but the group-execute bit is
off. This means mandatory locking will occur during access.
3. The 'T' means the sticky bit is on but execution is off. This is
undefined.
--
Tom Reingold
tr@samadams.princeton.edu OR ...!princeton!samadams!tr
"Warning: Do not drive with Auto-Shade in place. Remove
from windshield before starting ignition."sef@kithrup.COM (Sean Eric Fagan) (12/28/90)
In article <1990Dec26.011025.4186@NCoast.ORG> allbery@ncoast.ORG.ORG (Brandon S. Allbery KB8JRR) writes: >Some SCO Xenix, SCO "UNIX", and possibly SVR3.2 use setgid on non-executables >to indicate that normally cooperative file locking should actually be >mandatory. The SCO "UNIX" systems at work do not use g+s on files, however; >the command used is "chown +l". This is defined by the SVID, actually. I forget which version (I *think* 2, but am not certain, since I don't have a copy at home). As for the g+s vs. +l (the 'l' stands for 'mandatory locking', as is intuitively obvious 8-)), I think that was put in as a safety measue. (Don't know that sco put it in, mind you... could have been at&t.) >SunOS and maybe other Unixes use g+s on a directory to produce sticky gid's: >files created in the directory inherit the directory's gid instead of the >creating process's egid. Wow. SCO does that too (just checked). Neat... 8-) (I *honestly* didn't know it did it! *Really*!) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
thorinn@diku.dk (Lars Henrik Mathiesen) (12/29/90)
For plain files, that is, regular files with no execute bits set, I know of the following uses for these bits: The sticky bit is used to mark swap files of diskless clients under NFS. Updated blocks of such a file are written at once, like all NFS writes, but they are then immediately flushed from the server's block cache, on the theory that the server has better things to use its cache for. Also, the inode times may not be updated on such a write. (In principle, the foregoing holds for all writes, but the implementation I've seen only tests the bit on writes from the NFS server code --- and it always sets the inode time.) Under System V, and now SunOS 4, if a file has the setgid bit set but not the group execute bit, file locking on that file is mandatory: An exclusive lock on a segment of the file prevents all other processes from reading or writing it, while a shared lock only prevents writing. It only works for the fcntl and lockf styles of locking. -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk
bzs@world.std.com (Barry Shein) (12/29/90)
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-WRLDallbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/29/90)
As quoted from <BZS.90Dec28205902@world.std.com> by bzs@world.std.com (Barry Shein): +--------------- | 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. +--------------- Even if it wasn't in memory, V7 built new process images (execve()) on swap, so things were generally closer together that way. (But you already knew that, right? The only reason I'm a "guru" is that there aren't many real ones in northern Ohio.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
jfh@rpp386.cactus.org (John F Haugh II) (12/29/90)
In article <1990Dec29.050330.3390@NCoast.ORG> allbery@ncoast.ORG.ORG (Brandon S. Allbery KB8JRR) writes: >Even if it wasn't in memory, V7 built new process images (execve()) on swap, >so things were generally closer together that way. (But you already knew >that, right? The only reason I'm a "guru" is that there aren't many real ones >in northern Ohio.) More interestingly, the V7 swap space was all allocated contiguously so that a text image could be loaded with a single I/O operation. None of this wasteful paging mess with pages laying all over the place ;-) -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
barmar@think.com (Barry Margolin) (12/30/90)
In article <BZS.90Dec28205902@world.std.com> bzs@world.std.com (Barry Shein) writes: [Regarding sticky executables] >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. Actually, this is still useful on dataless workstations. Our dataless workstations have local swap, /, and /usr, but /usr/local generally comes from an NFS server. We've noticed significant performance improvement by setting the sticky bit on Lisp images, as it effectively causes the workstations to use their local swap space as a cache. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
guy@auspex.auspex.com (Guy Harris) (01/10/91)
In article <5114@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>>SunOS and maybe other Unixes use g+s on a directory to produce sticky gid's: >>>files created in the directory inherit the directory's gid instead of the >>>creating process's egid. >> >>Wow. SCO does that too (just checked). Neat... 8-) (I *honestly* didn't >>know it did it! *Really*!) > >4.3BSD added this (it may have appeared in other systems before that), >and SunOS and S5R3.x (for some value of "x", I think the correct value >is 2) picked it up from there. Brain fault - core dumped. Said brain saw "sticky" and "directory" and immediately read "sticky directory", not noting that the bit being talked about was the set-GID bit, rather than the sticky bit. (If "this" is taken as referring to the sticky bit on directories, the statements in the posting in question are correct.)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/11/91)
As quoted from <5128@auspex.auspex.com> by guy@auspex.auspex.com (Guy Harris): +--------------- | In article <5114@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: | >>>SunOS and maybe other Unixes use g+s on a directory to produce sticky gid's: | > | >4.3BSD added this (it may have appeared in other systems before that), | | Said brain saw "sticky" and "directory" and immediately read "sticky | directory", not noting that the bit being talked about was the set-GID +--------------- My fault, I being the one who posted the "| >>>" line: I made the same mistake while composing it ("g+s" with "s" meaning "sticky"). Of course, one could call the behavior "setgid", although with rather different meaning from the usual.... ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY