Date: Fri, 28 Sep 2001 07:29:47 +0000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: Seth Mos <knuffie@xs4all.nl>
Cc: Edward Cates <ed@cplane.com>, seth.mos@xs4all.nl, linux-xfs@oss.sgi.com
Subject: Re: XFS + NFS + UMASK
Message-ID: <20010928072947.G10761@boing.melbourne.sgi.com>
References: <200109271830.f8RIUTNM006799@mxzilla4.xs4all.nl> <4.3.2.7.2.20010928085122.03342320@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <4.3.2.7.2.20010928085122.03342320@pop.xs4all.nl>; from knuffie@xs4all.nl on Fri, Sep 28, 2001 at 08:55:25AM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, Sep 28, 2001 at 08:55:25AM +0200, Seth Mos wrote:
> CC'ing the list
> 
> At 11:29 27-9-2001 -0700, Edward Cates wrote:
> >I'm running Linxux 2.4.8-xfs with NFS v3 on:
> >dual 1 GHz PIII
> >2 GB RAM
> >Mylex DAC960 RAID card
> >5 Seagate Cheetah 73.4 GB hard drives
> >blah blah blah blah blah
> >
> >It all works beautifully, EXCEPT we can't get NFS to use any UMASK besides
> >022.  Is this an known XFS issue, or do I need to go bother someone else?
> 
Yes this would be a known unresolved issue, I'm afraid.
We will look at resolving this while merging kernel changes
with Andreas G.'s ACL/EA patch.


This problem is that we can't apply the umask if we have the chance
of having a default ACL on the dir.
In xfs acl code if we find out that it wasn't a default ACL after all,
then we apply the umask as usually is intended. But in the case of nfsd,
we shouldn't be applying the umask. (Steve's hack solution for nfsd)
Andi also had a possible solution (mentioned below).
More details are in an email I sent in mid August:

====================================================================
Date: Thu, 16 Aug 2001 14:07:19 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: Steve Lord <lord@sgi.com>
Cc: Andi Kleen <ak@suse.de>, Ken Cross <kcross@ntown.com>,
        Linux XFS <linux-xfs@oss.sgi.com>
Subject: Re: SPEC failures

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
> 
> Thanks,
> 
> 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.

--Tim
====================================================================