LinuxSA Mailing list archives

Index: [thread] [date] [subject] [author]
  From: Phil Nitschke <phil@caemrad.com.au>
  To  : linuxsa@linuxsa.org.au
  Date: 30 Mar 1999 21:57:43 +0930

Re: Permissions

>>>>> "AK" == Alan Kennington <akenning@dog.topology.org> writes:

  AK> Hmmm.  That's very odd.  If you type "chmod u+t <filename>" on a
  AK> sunos/solaris system, the stick bit it set.

  AK> But on a linux system, you have to type "chmod o+t <filename>".

  AK> That matches up better with the "ls" listing.  But why is it
  AK> different....?

My glibc-doc package contains the GNU C Library Reference manual in
info and HTML format ... and some other stuff...

Here is an (sizeable) extract from the info pages on` chmod':

  The Mode Bits for Access Permission
  -----------------------------------

     The "file mode", stored in the `st_mode' field of the file
  attributes, contains two kinds of information: the file type code, and
  the access permission bits.  This section discusses only the access
  permission bits, which control who can read or write the file.  *Note
  Testing File Type::, for information about the file type code.

     All of the symbols listed in this section are defined in the header
  file `sys/stat.h'.

     These symbolic constants are defined for the file mode bits that
  control access permission for the file:

  <...snip...>


  `S_ISVTX'
       This is the "sticky" bit, usually 01000.

       On a directory, it gives permission to delete a file in the
       directory only if you own that file.  Ordinarily, a user either
       can delete all the files in the directory or cannot delete any of
       them (based on whether the user has write permission for the
       directory).  The same restriction applies--you must both have
       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'; *note
       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.  In this use the sticky bit also says
       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).

I think that partially answers your question.

-- 
Phil.

-- 
Check out the LinuxSA web pages at http://www.linuxsa.org.au/
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject


Index: [thread] [date] [subject] [author]
Return to the LinuxSA Mailing List Information Page