xfs
[Top] [All Lists]

Re: umask fix (patch)

To: Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: umask fix (patch)
From: Steve Lord <lord@xxxxxxx>
Date: Fri, 27 Jul 2001 07:14:48 -0500
Cc: Steve Lord <lord@xxxxxxx>, Keith Owens <kaos@xxxxxxxxxxxxxxxxx>, tridge@xxxxxxxxxxx, linux-xfs@xxxxxxxxxxx, ag@xxxxxxxxxxx
In-reply-to: Message from Timothy Shimmin <tes@boing.melbourne.sgi.com> of "Fri, 27 Jul 2001 11:40:55 +1000." <20010727114055.N37341@boing.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
> Hi there,
> 
> On Thu, Jul 26, 2001 at 02:53:24PM -0500, Steve Lord wrote:
> > > On Wed, 25 Jul 2001 19:24:17 -0700 (PDT), 
> > > Andrew Tridgell <tridge@xxxxxxxxxxx> wrote:
> > > >The problem turned out to be in the nfsd code. The following fixes it:
> > > >
> > > >--- fs/nfsd/nfssvc.c    2001/05/29 19:53:13     1.13
> > > >+++ fs/nfsd/nfssvc.c    2001/07/26 02:27:26
> > > >@@ -150,6 +150,7 @@
> > > >        MOD_INC_USE_COUNT;
> > > >        lock_kernel();
> > > >        daemonize();
> > > >+       current->fs->umask = 0;
> > > >        sprintf(current->comm, "nfsd");
> > > >        current->rlim[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY; 
> > > 
> > > Kernel threads share the init task fs context.  That change makes all
> > > future kernel threads run with umask 0, a big security exposure.  This
> > > problem was supposed to have been fixed in 2.4.7-pre7.
> > 
> > There is an XFS bug in here, I am not quite sure how to fix it at the
> > moment though....
> > 
> > Basically the fix which went into 2.4.7-pre7 moved where the process 
> > umask was applied to the creation mask to be outside of vfs_create
> > and vfs_mkdir, NFS gets to pass in its own mask - presumably passed
> > along from the client with that umask applied.
> > 
> So where did this application of the umask get moved to ?
> Can the acl default test be moved to the new point where
> the umask is applied ?

Take a look at the callers of vfs_create and vfs_mknod in the current
tree, when coming from local accesses the umask is only applied if
there is no acl support in the filesystem, from NFS is is never
applied - but I presume the NFS client has already applied it.

So I have no idea how to make nfs client's behave correctly, they
are somewhat out of our control and the nfs spec probably says they
are supposed to do this.

Steve

> 
> This ACL code had to be added because we don't want
> the umask applied to the mode if the parent directory has 
> default ACLs to apply.  (following 1003.1e standard)
> So if the mode has the umask applied to it before we get to
> play with ACLs then we're stuffed.
> We have to stop the mode being changed at that point.
> Andreas did the same sort of thing with his EA/ACL patch;
> we checked with his code before doing this.
> 
> (So I'm not sure how we are going to keep to the standard
>  if NFS clients are going to modify the mode with the umask
>  before we get to see the mode - if that's what's happening)
> 
> --Tim
> 

Steve



<Prev in Thread] Current Thread [Next in Thread>