public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Nathan Scott <nathans@sgi.com>,
	Christoph Hellwig <hch@infradead.org>,
	Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
	Olaf Kirch <okir@suse.de>, Chris Mason <mason@suse.de>,
	Jeff Mahoney <jeffm@suse.com>
Subject: Re: [RFC] POSIX ACL kernel infrastructure
Date: Fri, 9 Aug 2002 14:22:49 +0200	[thread overview]
Message-ID: <200208091422.49879.agruen@suse.de> (raw)
In-Reply-To: <20020809121502.A8178@infradead.org>

On Friday 09 August 2002 13:15, Christoph Hellwig wrote:
> On Fri, Aug 09, 2002 at 12:53:55PM +0200, Andreas Gruenbacher wrote:
> > The kernel NFS daemon introduces a number of interesting problems in the
> > kernel that no other component requires; the ACL permission masking hack
> > is one of them. The hack affects NFSv2 and NFSv3
> >
> > It is really important that encode_fattr and encode_fattr3, the functions
> > that include the hack, are efficient; they are used in all the essential
> > NFS RPCs.
>
> IF it's so essential why are you doing another IOP call then instead of
> adding inkernel A retrieving to ->getattr and struct kstat?  encode_fattr*
> has to call it anyway and that's the logical place for ACLs..

I read this as `Why are you not returning the permissions nfsd should see in 
struct, which the inode->getattr IOP fills?'. Please correct me if this is 
not what you wanted to say.

The usual callers of getattr should see the unmasked permissions; it's only 
nfsd that needs this special treatment, and only on filesystems that have 
ACLs enabled. The getattr IOP is used by others as well.

If you had adding an extra field to struct kstat in mind, this just seems too 
intrusive to me for solving the nfsd problem. The problem will go away in the 
future when all NFSv3 clients are using the ACCESS RPC, anyway. It's just a 
hack right now.

-Andreas.

------------------------------------------------------------------
 Andreas Gruenbacher                                SuSE Linux AG
 mailto:agruen@suse.de                     Deutschherrnstr. 15-19
 http://www.suse.de/                   D-90429 Nuernberg, Germany


  reply	other threads:[~2002-08-09 12:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-04 13:46 [RFC] POSIX ACL kernel infrastructure Andreas Gruenbacher
2002-08-04 14:04 ` Christoph Hellwig
2002-08-04 14:14   ` Andreas Gruenbacher
2002-08-04 14:33     ` Christoph Hellwig
2002-08-05 12:11       ` Andreas Gruenbacher
2002-08-05 12:28         ` Christoph Hellwig
2002-08-09  2:02           ` Nathan Scott
2002-08-09 10:53             ` Andreas Gruenbacher
2002-08-09 11:15               ` Christoph Hellwig
2002-08-09 12:22                 ` Andreas Gruenbacher [this message]
2002-08-09 12:32                   ` Christoph Hellwig
2002-08-09 13:17                     ` Andreas Gruenbacher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200208091422.49879.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=hch@infradead.org \
    --cc=jeffm@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mason@suse.de \
    --cc=nathans@sgi.com \
    --cc=okir@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox