How do I find info about "sticky bits" from within Linux without having to use Google?

2

When I type:

$ man -k sticky

I get:

sticky: nothing appropriate

Surely there is information within the Linux OS somewhere (without having to go to Google) about sticky bits - what they are, how to set them on directories, etc.

Of course I've found relevant info on this topic on Wikipedia and elsewhere by using Google, but I want to know how to look it up within Linux itself (I'm using CentOS v6.3).

Worn Drellis

Posted 2013-04-28T16:03:33.050

Reputation: 65

Answers

2

Try:

man 2 chmod

Or, if you feel like digging through source,

vi /usr/include/sys/stat.h

Possibly also helpful (though absent from CentOS 6, per DanielBeck's comment):

man 8 sticky

ron rothman

Posted 2013-04-28T16:03:33.050

Reputation: 135

3

man 1 chmod

http://linux.die.net/man/1/chmod :

Restricted Deletion Flag or Sticky Bit

The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.

Hope it helps !

Paul

Posted 2013-04-28T16:03:33.050

Reputation: 131

0

If you have Emacs (or any Info browser) and the GNU C Library Reference Manual installed, you can do this:

  1. Start Emacs and press Ctrl-h i (or click “Help > More Manuals > All Other Manuals (Info)”) to start its built-in Info reader.
  2. Press m (or click on “Info > Menu item > Other”)
  3. Type libc and press Enter.
  4. Type i (or click on “Info > Index > Lookup a String…”)
  5. Type sticky and press Enter.

You will get this text:

‘S_ISVTX’

This is the "sticky" bit, usually 01000.

For a directory it gives permission to delete a file in that directory only if you own that file. Ordinarily, a user can either delete all the files in a directory or cannot delete any of them (based on whether the user has write permission for the directory). The same restriction applies--you must have both write permission for the directory and own the file you want to delete. The one exception is that the owner of the directory can delete any file in the directory, no matter who owns it (provided the owner has given himself write permission for the directory). This is commonly used for the ‘/tmp’ directory, where anyone may create files but not delete files created by other users.

Originally the sticky bit on an executable file modified the swapping policies of the system. Normally, when a program terminated, its pages in core were immediately freed and reused. If the sticky bit was set on the executable file, the system kept the pages in core for a while as if the program were still running. This was advantageous for a program likely to be run many times in succession. This usage is obsolete in modern systems. When a program terminates, its pages always remain in core as long as there is no shortage of memory in the system. When the program is next run, its pages will still be in core if no shortage arose since the last run.

On some modern systems where the sticky bit has no useful meaning for an executable file, you cannot set the bit at all for a non-directory. If you try, ‘chmod’ fails with ‘EFTYPE’; see Setting Permissions.

Some systems (particularly SunOS) have yet another use for the sticky bit. If the sticky bit is set on a file that is not executable, it means the opposite: never cache the pages of this file at all. The main use of this is for the files on an NFS server machine which are used as the swap area of diskless client machines. The idea is that the pages of the file will be cached in the client’s memory, so it is a waste of the server’s memory to cache them a second time. With this usage the sticky bit also implies that the filesystem may fail to record the file’s modification time onto disk reliably (the idea being that no-one cares for a swap file).

This bit is only available on BSD systems (and those derived from them). Therefore one has to use the ‘_BSD_SOURCE feature select macro to get the definition (see Feature Test Macros).

Teddy

Posted 2013-04-28T16:03:33.050

Reputation: 5 504