Modes on directories vs force group etc

[Cole, Timothy D.]

> -----Original Message-----
> From:	Richard Sharpe [SMTP:sharpe at ns.aus.com]
> Sent:	Monday, June 28, 1999 20:33
> To:	Multiple recipients of list
> Subject:	Modes on directories vs force group etc
> 
> Hi,
> 
> I am interested in the history of parameters like force user and force
> group vs setting SETUID and SETGID bits on a directory etc ...
> 
> What are the pros and cons? 
> 
	force user in Samba essentially cause the logged in user to "become"
the specified user for all file operations.  It should be understood that
it's not a mechanism to "give away" files to the specified user.  It's only
safe (and useful) in very specific settings.

	force group simply sets the logged in user's primary group to the
specified group, preserving any other group memberships.  It is more
appropriate to situations where you wish a bunch of users to share files
with each other -- after all, that's what groups are for.  It also allows
you to use that group to control what can be shared and what cannot.  It's
still probably not appropriate for shares used by a number of different
projects.  It is not necessary for the user to normally be a member of this
group.

	smb.conf(5) goes into a little more detail about this.

> Clearly, in a directory with the T bit set, the UID gets set to the logged
> on user.
> 
	Well, that's true, strictly speaking, but the UID is always set to
the user when creating a file whether or not the 'T' bit is set (unless
you're using force user in Samba, in which case the logged in user will
actually be that user anyway).  't' has no significance for creating files.

	More on the various bits (feel free to correct me if I'm off
somewhere):

	All three of the special bits were originally only meaningful for
executables.

	suid and sgid, 04000 and 02000 (and the notion of effective group
and user ids) were introduced early in Unix history; Thompson, I believe,
actually got a patent on them.  At that time, their only significance was to
set the effective user or group id of the new process to the user or group
id of the file, respectively.

	The "sticky" bit, 't', 01000, I think predates the suid and sgid
bits.  It inidicated that the executable's text segment should be saved on
the swap media after the process terminated.  This was especially useful for
often-run tools like "ls".  (originally, Unix swapped entire processes in
and out of core instead of paging, as it does today)  As virtual memory,
persistent storage performance and disk cacheing got better, its original
meaning became obsolete.

	As time passed, the special bits (so far unused for non-executables)
were called into service to control other aspects of Unix behavior.

	One nagging problem in world-writable shared directories like /tmp
had always been a user's ability to delete files created and owned by other
users.  For non-public directories, that's often desirable, but if just
anyone can come in and, say, delete or replace one of your text editor's
working files, that's a potential headache, as well as a security problem.

	As a result of such problems, the "sticky" bit found a new use in
specifying that links to a file could not be renamed or removed from a
directory by anyone but the directory or file owner.  It does not have any
influence over other operations, including the creation of links.  (as a
side note, the new use of the sticky bit also made the owner of a symlink
meaningful for the first time, as it now determines who can delete or rename
a symlink in a "sticky" directory)

	The current use of sgid on directories was introduced in BSD.  It
causes any new files or subdirectories in such a directory to be created
with their parent's group, and new subdirectories to inherit their parent's
sgid bit, _iff the creating user is a member of that group_.

	More recently, with the introduction of mandatory locking in Unix,
the sgid bit was pressed into service in yet another role:  if sgid is set
on a file for which the group does not have execute permission, fcntl()
locks on the file will be mandatory (causing a process to block if it tries
to operate on a portion of a file locked by someone else), else fcntl() will
observe the traditional, discretionary, Unix behavior.