Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] ubifs: replay: Detect and kill orphaned xattrs
Date: Mon, 09 Oct 2017 15:56:56 +0200	[thread overview]
Message-ID: <13583464.gMdCSCRoQZ@blindfold> (raw)
In-Reply-To: <e3239508-fe96-0d42-af70-d735eec78f2d@pengutronix.de>

Am Montag, 9. Oktober 2017, 15:49:56 CEST schrieb Marc Kleine-Budde:
> On 06/26/2017 01:19 PM, Richard Weinberger wrote:
> > Creating an xattr is an independent journal transaction and the xattr
> > code assumes that there is always a valid host inode present when a new
> > xattr is created. This assumption is not correct for LSM and now
> > fscrypt, for these users UBIFS creates the xattr before the host inode
> > is created and visible to the user. Since these are two journal
> > transactions it can happen that due to a power-cut only the xattr is
> > present but not the host inode nor the directory entry for it. As result
> > of this UBIFS will lose free space and can run out of space at some
> > time.
> > It is also not possible to create the xattr after the host inode because
> > this would violate LSM and fscrypt model. After a power-cut we could end
> > up with a inode without security context.
> > 
> > This is an intermediate fix that can go into -stable, as long term
> > solution we have to make sure that creating the xattr and the host inode
> > is a single journal transaction. But to achieve this the journal code
> > need some rework first.
> > 
> > Cc: Subodh Nijsure <snijsure@grid-net.com>
> > Cc: Marc Kleine-Budde <mkl@pengutronix.de>
> > Cc: Ben Shelton <ben.shelton@ni.com>
> > Cc: Brad Mouring <brad.mouring@ni.com>
> > Cc: Terry Wilcox <terry.wilcox@ni.com>
> > Cc: Gratian Crisan <gratian.crisan@ni.com>
> > Cc: stable@vger.kernel.org
> > Fixes: d7f0b70d30ff ("UBIFS: Add security.* XATTR support for the UBIFS")
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> 
> What happended to this patch? It's not on mainline (and thus not on the
> stable branches). Was there a better fix?

Since the patch is non-trivial I hoped to get a review or tested-by.
Therefore I didn't merge it so far.

Thanks,
//richard

  reply	other threads:[~2017-10-09 13:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 11:19 [PATCH] ubifs: replay: Detect and kill orphaned xattrs Richard Weinberger
2017-10-09 13:49 ` Marc Kleine-Budde
2017-10-09 13:56   ` Richard Weinberger [this message]
2017-10-09 13:59     ` Marc Kleine-Budde
2017-10-09 14:06       ` Richard Weinberger
2017-10-09 14:32         ` Marc Kleine-Budde

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=13583464.gMdCSCRoQZ@blindfold \
    --to=richard@nod.at \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mkl@pengutronix.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