On Wed, Aug 15, 2001 at 02:34:21PM -0500, Steve Lord wrote:
> > On Wed, Aug 15, 2001 at 10:30:46AM -0500, Steve Lord wrote:
> > > Andrew had the approach of setting the umask of the nfsd process to 0 at
> > > startup, there was some other reason for this not being popular.
> > He did it for init_task, which disturbed all other kernel threads too
> > and opened tons of security holes.
> > The right way IMHO is to give nfsd an own fs_struct and set umask there,
> > as in this patch.
> > -Andi
> Care to try this one on Neil Brown or Trond?
> I wonder if the acl project
> has run into the same issue?
I would say the answer is yes.
On Aug 2, Andreas released a new patch, 0.7.15, for the 2.4.7 kernel.
Having a quick scan of the patch he has definitely changed
where the umask is applied in the case of no default ACL.
He has also patched some nfsd code.
It would be worth going through this patch carefully...:)
> The tricky part in justifying this is nothing
> in the main kernel needs this change right now.
Just to be sure I understand what is going on...
Previously, the umask was applied to the mode in
vfs_mkdir(), vfs_mknod() and vfs_create().
In 2.4.7, the umask code was moved to sys_mkdir(),
sys_mknod() and open_namei() respectively,
to just before where the vfs_*() calls are being made.
The other caller of these particular vfs_*() calls
is nfsd_create [linux/fs/nfsd/vfs.c].
So by moving the umask code out it means that nfsd_create()
will no longer be calling the vfs functions which were
setting the umask.
But in the XFS inode operations, where we set up
linvfs_create(), linvfs_mkdir() and linvfs_mknod(),
we are still applying the umask if no default ACL exists.