Message-Id: <200107261953.f6QJrO518223@jen.americas.sgi.com>
To: Keith Owens <kaos@melbourne.sgi.com>, tridge@valinux.com
cc: linux-xfs@oss.sgi.com
Subject: Re: umask fix (patch) 
In-Reply-To: Message from Keith Owens <kaos@melbourne.sgi.com> 
   of "Thu, 26 Jul 2001 13:11:56 +1000." <18265.996117116@kao2.melbourne.sgi.com> 
Date: Thu, 26 Jul 2001 14:53:24 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Wed, 25 Jul 2001 19:24:17 -0700 (PDT), 
> Andrew Tridgell <tridge@valinux.com> 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.

The problem is the acl code added in the xfs patch. There is code in
the mainline kernel which skips the umask if the filesystem has acl
support defined in a superblock flag, the filesystem then applies the
umask itself if there is no default acl for that directory. So this
chunk of code in the xfs create path:


fs/xfs/linux/xfs_iops.c
        have_default_acl = _ACL_GET_DEFAULT(dvp, &pdacl);
        if (!have_default_acl) {
            mode &= ~current->fs->umask;
        }

Will be applying the process umask even if we are coming from nfs, negating
the fix in the vfs & nfs code.

So far the only 'workaround' I can come up with is this:

	have_default_acl = _ACL_GET_DEFAULT(dvp, &pdacl);

	if (strcmp(current->comm, "nfsd") && !have_default_acl) {
		mode &= ~current->fs->umask;
	}

I think that would fix it, but I really don't like it.

Steve