jik@athena.mit.edu (Jonathan I. Kamens) (03/20/91)
In article <6704@navy28.UUCP>, seda@motcid.UUCP (Joseph W. Seda) writes: |> What does the stick bit do? I could look through all the man pages and probably |> still not find all the details. Can someone help? On a file? A directory? Is it executable or not? What kind of Unix are you using? On my system (4.3BSD-based), there is a sticky(8) man page that describes in detail what the sticky bit does. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
gilbertd@p4.cs.man.ac.uk (Dave Gilbert) (03/22/91)
In <6704@navy28.UUCP> seda@motcid.UUCP (Joseph W. Seda) writes: >What does the stick bit do? I could look through all the man pages and probably >still not find all the details. Can someone help? As far as I'm aware what it does is do something like try and keep programs in memory -so that say you have 20 people using vi on a machine, it ould only hold 1 copy and also it would keep it in memory so its available immediatly Dave (I think I'm correct?) -- ------------------------------------------------------------------------------- - Dave Gilbert - gilbertd@p4.cs.man.ac.uk - The MTBF of a piece of equipment - - G7FHJ@GB7NWP - is inversly proportional to its - ------------------------------------------- importance -
dvldbg@cs.umu.se (Daniel Brahneborg) (03/25/91)
In <6704@navy28.UUCP> seda@motcid.UUCP (Joseph W. Seda) writes: >What does the stick bit do? I could look through all the man pages and probably >still not find all the details. Can someone help? The sticky bit is used for changing the user-id of the process that runs the program, such as 'su', and lots of others. The id is set to the user of the file, which in this case almost always is root. You can also have the group id changed. Check the manual pages for chmod, they should tell you the details. /Basic
goehring@gnu.ai.mit.edu (Not Marc Spencer) (03/25/91)
In article <gilbertd.669645050@p4.cs.man.ac.uk> gilbertd@p4.cs.man.ac.uk (Dave Gilbert) writes:
As far as I'm aware what it does is do something like try and keep
programs in memory -so that say you have 20 people using vi on a
machine, it ould only hold 1 copy and also it would keep it in
memory so its available immediatly
Dave (I think I'm correct?)
While the `sticky bit' is set on a sharable executable file, the text
of that file will not be removed from the system swap area. Thus the
file does not have to be fetched from the file system upon each
execution. Shareable text segments are normally placed in a
least-frequently-used cache after use, and thus the `sticky bit' has
little effect on commonly-used text images.
If the sticky bit is set on a file which has none of its execute bits
set, then the kernel's buffer cache will not be used for accesses to
the file. This can be used on large files (such as swap files for
diskless NFS clients) so that accesses to these files will not blow
everything else out of the server's buffer cache.
A directory whose `sticky bit' is set becomes an append-only
directory, or, more accurately, a directory in which the deletion of
files is restricted. A file in a sticky directory may only be removed
or renamed by a user if the user has write permission for the
directory and the user is the owner of the file, the owner of the
directory, or the super-user. This feature is usefully applied to
directories such as /tmp which must be publicly writable but should
deny users the license to arbitrarily delete or rename each others'
files. A directory whose `sticky bit' is set becomes an append-only
directory, or, more accurately, a directory in which the deletion of
files is restricted. A file in a sticky directory may only be removed
or renamed by a user if the user has write permission for the
directory and the user is the owner of the file, the owner of the
directory, or the super-user. This feature is usefully applied to
directories such as /tmp which must be publicly writable but should
deny users the license to arbitrarily delete or rename each others'
files.
--
Help stamp out vi in our lifetime!
Scott Goehring goehring@gnu.ai.mit.edu
On exile in Indianapolis, INrickert@mp.cs.niu.edu (Neil Rickert) (03/25/91)
In article <1991Mar24.223426.10401@cs.umu.se> dvldbg@cs.umu.se (Daniel Brahneborg) writes: >In <6704@navy28.UUCP> seda@motcid.UUCP (Joseph W. Seda) writes: >>What does the stick bit do? I could look through all the man pages and probably >>still not find all the details. Can someone help? > >The sticky bit is used for changing the user-id of the process that Nonsense. >Check the manual pages for chmod, they should tell you the details. I suggest you follow your own advice. Today the sticky bit is often used on public directories (such as /tmp) with the meaning that only the owner of a file can 'rm' that file. The original meaning applied to executables. It meant that the executable was to remain always in memory, even when not in use. This is an efficiency consideration for binaries which are likely to be in use in many processes at one time. /bin/sh would be an obvious candidate. (Of course this applies only to the text section, and not to data and bss). This use probably still applies in some systems. However, with the use of virtual memory, and the paging of binaries right out of the executable file, the need has disappeared in many Unix versions. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
curt@cynic.wimsey.bc.ca (Curt J. Sampson) (03/25/91)
In article <1991Mar25.012637.10647@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > Today the sticky bit is often used on public directories (such as /tmp) with > the meaning that only the owner of a file can 'rm' that file. > > The original meaning applied to executables. It meant that the executable > was to remain always in memory, even when not in use. Keep in mind that the newer meanings of the sticky bit, such as making a directory "append-only," may not apply to many UNIX systems. My SCO Xenix 2.3.2 will not recognise a sticky bit on a directory. On my 286 system its only use is to keep text segments in the swap space. On the 386 versions, since they use virtual memory, not even that applies. cjs -- | "It is actually a feature of UUCP that the map of curt@cynic.uucp | all systems in the network is not known anywhere." curt@cynic.wimsey.bc.ca | --Berkeley Mail Reference Manual (Kurt Schoens)
akes@mcshh.hanse.de (Andreas Kessemeier) (03/26/91)
gilbertd@p4.cs.man.ac.uk (Dave Gilbert) writes: >In <6704@navy28.UUCP> seda@motcid.UUCP (Joseph W. Seda) writes: >>What does the stick bit do? >As far as I'm aware what it does is do something like try and keep programs >in memory -so that say you have 20 people using vi on a machine, it ould >only hold 1 copy and also it would keep it in memory so its available immediatly Sorry, but only a half hit :-) The sticky bit doesn't tell the system to hold the job in memory. This can only be done with lock(S) and is very dangerous, because it can lead to complete deadlock. The sticky bit tells the kernel to not delete the copy of the text- segment in swapspace after use. If the programm is called next time it is much cheaper to grab the text out of swap rather than reading the file. This is because swap is always physikal sequential on disk while a file may be fragmented. On the other hand, the overhead for reading out of swap is much less than reading a file. Greets, Andreas -- Andreas Kessemeier akes@mcshh.hanse.de There is no way to Freedom. Freedom is the way.
art@pilikia.pegasus.com (Art Neilson) (03/26/91)
In article <1991Mar24.223426.10401@cs.umu.se> dvldbg@cs.umu.se (Daniel Brahneborg) writes: >In <6704@navy28.UUCP> seda@motcid.UUCP (Joseph W. Seda) writes: >>What does the stick bit do? I could look through all the man pages and probably >>still not find all the details. Can someone help? > >The sticky bit is used for changing the user-id of the process that >runs the program, such as 'su', and lots of others. >The id is set to the user of the file, which in this case >almost always is root. You can also have the group id changed. >Check the manual pages for chmod, they should tell you the details. I think you are confusing the setuid bit with the sticky bit. The sticky bit means different things depending if it's set on a binary or a directory. The sticky bit when set on a binary file means save the text section (i.e. code) in memory or swap upon termination. When the program is next invoked, the program text is already resident which results in much faster load times. Frequently executed programs such as ls can benefit greatly from this. Some UNIX releases such as BSD and newer versions of SYS5 have support for the sticky bit set on directories. In this case, if a directory is writable and has the sticky bit set, files within that directory can only be removed if one or more of the following is true: the user owns the file the user owns the directory the file is writable by the user the user is root -- Arthur W. Neilson III | INET: art@pilikia.pegasus.com Bank of Hawaii Tech Support | UUCP: uunet!ucsd!nosc!pilikia!art
lbr@holos0.uucp (Len Reed) (03/27/91)
In article <1991Mar24.223426.10401@cs.umu.se> dvldbg@cs.umu.se (Daniel Brahneborg) writes: >The sticky bit is used for changing the user-id of the process that >runs the program, such as 'su', and lots of others. I'll be charitable and assume that this was a mental slip and not really and indication that you don't know what you're talking about. What you say is certainly wrong. You've just described the set-uid bit, though a complete explanation of that bit would require that you say what the user id is changed to and a brief description of effective versus real user ids. I don't understand why persons post erroneous answers to simple questions. Again, perhaps this wrong answer was a mental slip, but others have posted wrong answers to this question that show, without a doubt, they don't know what they're talking about. The sticky bit goes back to at least edition 6 Unix; we're talking the 1970s here. In a classic sense it applicable only to executables--not even shell scripts. It can be set only by the superuser. It says that when the last process executing this inode dies, do *not* discard the sharable text from the swap area, but keep it in the swap area. When someone later exec's the program, the kernel doesn't have to load the text from the file, only the initialized data. This allegedly speeds startup of progams that are used frequently (e.g., vi). It has no effect on programs that the shell that tend to always have one or more processes running them. The meaning is expandable to systems with paging virtual memory: retain the sharable pages. The sticky bit (and the setuid and setgid bits, for that matter) have been appropriated for various uses on BSD and perhaps other systems; others have written about these uses. My description of the sticky bit is the only one applicable to "Unix" in general. -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr
guy@auspex.auspex.com (Guy Harris) (04/02/91)
>My description of the sticky bit is the only one applicable to "Unix" >in general. Depends on your definition of "'Unix' in general." It doesn't apply to SunOS 4.x, and possibly not to S5R4 as well; SunOS 4.x doesn't interpret the sticky bit as meaning "keep a swap image around" (it's not necessarily an "image" in any case; pages paged in directly from the file, and not copied-on-a-write, do *not* have copies in swap space).