Re: [RFC] Apply the umask in VFS optionally (also POSIX ACL kernel infrastructure)

[Christoph Hellwig <hch@infradead.org>]

On Sun, Aug 04, 2002 at 03:46:43PM +0200, Andreas Gruenbacher wrote:
> I believe that (2) is the more reasonable choice in this case, so I propose
> this patch, which adds the MS_NOUMASK mount option. The flag is set by the
> file system, if the file system does not want the VFS to apply the umask,
> after which the file system itself is responsible for applying the umask
> where appropriate.

In the current XFS trees we have that flag as IS_POSIXACL() and S_POSIXACL
inod flag. (And I think some of your 2.4 patches do the same).  After some
thinking a per-superblock flag looks best to me, but instead of naming it
MS_NOUMASK I'd really, really prefer MS_POSIXACL.  Rationale:

(1) there is not much other reasoning why we shouldn't apply the umask
(2) this way lowlevel filesystem drivers can enabled/disable acl
    per-mountpoint or even on-the-fly (if remount implements it)

> Finally, I have a question related to this. We had a bug with kernel tasks,
> which don't have a umask associated with them (nfsd in particular). Should
> kernel tasks that create files be required to have a valid fs_struct (which
> includes the umask), or should this be special cased in file systems?

Anything that deals with files shall have a valid fs_struct.  The number
of in-kernel threads that are supposed to deal with files is extremly
low (only in-kernel fileservers like nfsd, tux or the now dead khttpd)
and not worth workarounds in filesystem code.  Not to mention it is much
more elegant.