Robert Elz <kre@munnari.OZ.AU> writes:

  > where things don't work very well.    That is, if you have your default
  > umask set to allow group writes, which can be useful if working on a group
  > project, then when you create files in some public place like /tmp, some
  > random group tends to get write permission on your file.

The difficulty I see often is if you set up an area owned by a group
you probably want all the files in that area readable, writeable and
modifiable by members of the group, but that doesn't happen by default
unless people have a 00x umask. A 00x umask has the problem that files
created elsewhere are also by default group read/writeable.

You can sort of work around this by making your home directory (say)
700 and umask 022, but that is a bit inflexible. You can't then create
a subdirectory under your home directory for everyone else in your
group to use.

I would like to see a bit which meant "use the permissions of the
directory as a default for files or directories created within
it". Probably with umask applied as well.

Then you can have umask 00x, and set the mode on your home directory
to 4755. This would have the effect of an 022 umask when files are
created within your home directory, but an 002 umask in directories
without the suid bit set. Probably you would want subdirectories of
directories with the suid bit set to also have the suid bit set by
default.

I don't see a lot of use for the original "can't create subdirectory"
proposal. Denial of service can be done just by creating a huge single
file and there are a lot of good reasons for wanting to create a
directory.  If people are keeping stuff there long term to avoid
quotas, the best solution I could come up with was a cron job to
remove files over x days old except those owned by root. Also a well
promulgated policy to the effect that tmp files are subject to removal
without notice and are not backed up should help.

Ian