linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: Ashish Sangwan <ashishsangwan2@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Fuse: Add mount option to cache presence of security related xattr
Date: Wed, 31 Aug 2016 10:04:16 -0700	[thread overview]
Message-ID: <87twe0ooof.fsf@thinkpad.rath.org> (raw)
In-Reply-To: <1472625363-4850-1-git-send-email-ashishsangwan2@gmail.com> (Ashish Sangwan's message of "Wed, 31 Aug 2016 12:06:03 +0530")

On Aug 31 2016, Ashish Sangwan <ashishsangwan2@gmail.com> wrote:
> In case of a write call on any file, there is a xattr lookup call for
> security.capablities type of xattr which is a scaling bottleneck.
> In some of our use cases, just enabling the xattr support, we are
> experiencing a performance drop of almost 20% even though the file does
> not have any security xattr.
> Fuse, by default, does not remember the presence of security attributes as
> it clears the MS_NOSEC flag at the time of fill super and hence requires a
> lookup of security xattr at each write. This makes sense in case of network
> filesystems where multiple clients can change the state of xattr.
> This patch adds a new mount option cache_security_xattr_presence
> to avoid clearing MS_NOSEC flag. This could be use by the filesystem
> implementations which supports xattr but are local in nature OR the
> implementations which has its own security policies and
> do not support security.capablities xattr.


If I remember correctly, FUSE does not support LSMs at all, so even if
there is a security.capabilities xattr it won't have the expected
effect. So maybe it makes more sense to unconditionally catch both read
and write of security.capabilites in kernel and never forward it to
userspace?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

  reply	other threads:[~2016-08-31 17:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31  6:36 [PATCH] Fuse: Add mount option to cache presence of security related xattr Ashish Sangwan
2016-08-31 17:04 ` Nikolaus Rath [this message]
     [not found]   ` <87twe0ooof.fsf-Zv899e0YUSYPWKMTL/zdXNi2O/JbrIOy@public.gmane.org>
2016-09-06  8:47     ` Ashish Sangwan
2016-09-10  4:00       ` Ashish Sangwan
2016-09-15 14:15       ` Miklos Szeredi

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=87twe0ooof.fsf@thinkpad.rath.org \
    --to=nikolaus@rath.org \
    --cc=ashishsangwan2@gmail.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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;
as well as URLs for NNTP newsgroup(s).