Re: [NFS] [PATCH] Bug in NFS - should init be allowed to set umask???

[Neil Brown]

On Saturday July 14, [e-mail] wrote:
> 
> 
> On Sat, 14 Jul 2001, Neil Brown wrote:
> 
> > On Friday July 13, [e-mail] wrote:
> > > 
> > > On Sat, 14 Jul 2001, Neil Brown wrote:
> > > >
> > > > I've found a 4th option.  We make it so that fs->umask does not affect
> > > > nfsd
> > > 
> > > Me likee.
> > > 
> > > Applied. I'd only like to double-check that you made sure you changed all
> > > callers?
> > 
> > There is just the call to vfs_mknod in net/unix/af_unix.c that I
> > mentioned.  I'm not sure what to do about that one.
> > 
> > A
> >     find -name '*.[ch]' | xargs egrep 'vfs_(mkdir|mknod|create)'
> 
> RTFM grep(1). \< is your friend...

But then you don't get to see and inspect random samplings of the
kernel, and thereby increase your general knowledge.
The false-positive of devfs_mknod gives a remarkable (if inacurate)
inside into the relationship between vfs and de-vfs :-)

Similarly searching for "umask" finds lots of matches for cpumask and
so it a steping stone into learning more about SMP infrastructure....
:-)

It's call "stratified sampling" and can be a more effective way to
sample a large body of data than put random sampling.

> 
> >   2 matches in net/unix/af_unix.c  one is a comment, the other is the
> >                                    one in question
> > 
> > To be maximally conservative, you might want to apply this patch,
> > just in case it is important.
> 
> It is. Ability to connect == write permissions on AF_UNIX socket. So
> umask matters.

I certainly appreciate that permissions on an AF_UNIX socket matter,
but wondered why they were set to "sock->inode->i_mode" rather than
simply 0666.  Maybe - I thought - sock->inode->i_mode already has the
umask applied in some way, and so re-appling it was not necessary.
Where-from comes the mode that is in sock->inode->i_mode ?

NeilBrown