I have some uncommitted changes to add a new mount flag, `usergid', whose
presence indicates System V semantics for inode creation, as follows:

- When the mount flag is not set (the default), new inodes will be owned by
  the effective uid of the creating user, and the gid of the inode's parent
  directory.  (BSD semantics)

- When the mount flag is set, new inodes will be owned by the effective uid
  of the creating user, and the gid of:

    * the parent directory, if the parent directory's set-group-id bit
      is set.

    * the creating user's primary effective gid, if the parent directory's
      set-group-id bit is not set.

  (System V semantics)

There are uses for the System V semantics, for which this thread is _not_ a
forum.  I am running on the assumption that a non-default mount option for
this functionality is acceptable, from prior discussion.

Now, such a change would not alter default behavior, but does require:

- consuming another global mount flag (only two left, although the `flags'
  marking state information not visible to statfs() could move to another
  field in `struct mount', freeing up 9 more bits),

- adding documentation to mount.8 about the flag's purpose and its impact on
  group quota semantics,

- adding set-group-id bits to some directories in etc/mtree/NetBSD.dist to
  allow proper working of a NetBSD install with this mount option set for /
  or /var,

- adding code to ufs to honor this flag (for ffs, mfs, and ext2fs).

=====

This is up for comment only because nfs is a special case.  At the moment,
nfs uses the server's semantics for file creation.  Because nfs is also
governed by quotas on the remote machine, I'd be inclined _not_ to implement
support for overriding that behavior, using "the server knows what's best
for the server" as argument.  On the flip side, if this is implemented for
nfs, there should be a separate, nfs-specific mount option that says "honor
the client's gid semantics setting", required in tandem with [no]usergid.

Thoughts on this last point?

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  http://www.wasabisystems.com/
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.