*****************************************************************************
This Email and files transmitted are confidential and intended solely for
the use of the individual or entity to whom they are addressed. If you
have received this Email in error please notify the system manager.
Please note that any views or opinions presented in this Email are solely
those of the author and do not necessarily represent those of IndusInd
Bank Ltd. Finally, the recipient should check this Email and any
attachments for the presence of viruses. IndusInd Bank Ltd. accepts no
liability for any damage caused by any virus transmitted by this Email.
*****************************************************************************
** Message has been scanned by Emergic MailServ **

In addition to the basic permissions there are also three bits of information defined for files in UNIX:

SUID or setuid: change user ID on execution. If setuid bit is set, when the file is executed by a user, the process will have the same rights as the owner of the file being executed.
SGID or setgid: change group ID on execution. Same as above, but inherits rights of the group of the owner of the file. For directories it also may mean that when a new file is created in the directory it will inherit the group of the directory (and not of the user who created the file).

Sticky bit. Historically It was used to trigger process to "stick" in memory after it executes, now this usage is obsolete. Currently its use is system dependant and it is mostly used to suppress deletion of the files that belong to other users in the folder where you have "write" access to.
these are set as a fourth digit in numerical chmod commands

Please also recall that setting the user or group sticky bit on a directory forces all files created within the directory to be created with the parent owner or group and parent owner or group permissions, on most *nix OEs.
(As opposed to the setting the "other" sticky bit to protect users files from deletion (as in /tmp)).

1)for file t permission is good for very old unix and means file will
remain in memory after execution(similar resident programs)
2)sticky bit for directory means, the owner of object under directory can
remove or manipulate it

The sticky bit is often used with
shared directories to allow for greater ease of management. This bit can allow all
users to write to the directory but allow only a file owner to delete a file within the
directory.
This allows many users to share files within the directory and prevents
someone from overwriting or deletes files that don’t belong to that user.
The sticky bit uses the numeric value of "1" and the alphabetic value of "t".

hhvrl> a sticky bit can also be applied to a single file with
hhvrl> chmod u+s filename

hhvrl> or

hhvrl> chmod 4755 filename

Yeah, but what does it _DO_ to the file?

In the "old days" sticky bit was set on commonly used utilities -
executable files. Code and read-only data was shareable between
processes. If the sticky bit was set, the Kernel would keep the
read-only code from a process in memory for a while in case a new
process started up using the same executable.

No idea if this still works in any system, of if the sticky bit is
used to control something else this century.

avrl> You are not reading from a Linux man page for this. You are
avrl> reading from either Solaris or HPUX.

You're right there. I started out in Unix BSD (Berkeley System
Development) in around 1979. The performance improvement from not
reloading executable code every time it was called, and sharing code
segments, was important then. It doesn't count now - CPUs are x1000
faster and x1000 more RAM (my first Unix ran on a Perq - 1MB, 8MHz,
and 2 x 360KB 8-inch floppies - a 20MB hard disk came along later).

BSD had optimisations like this:

You make another process by fork(), and you load another executable by
exec(). After a fork(), BSD would unschedule the Parent and run the
Child. If the next system call was exec(), then it knew it could omit
most of the overheads for the fork() (like making swap space for the
child, and copying all the data, and so on) and it just launched the
new process as a clean exec(). If the child did not exec(), kernel
finished off the duplication and ran the parent and child in parallel.
95% of the time, it won on the deal.

So the question is what does setting GID on a directory or the Sticky bit for that matter.
Setting the sticky (t or 1777) on the directory will only allow the owner of a file to delete the file.
Setting SGID on a directory forces all files (directories) created in the directory or below to be created with the group ownership set on the directory.