public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: sandeen@redhat.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 01/11] xfs_repair: examine all remote attribute blocks
Date: Fri, 4 May 2018 12:23:37 -0700	[thread overview]
Message-ID: <20180504192337.GJ26569@magnolia> (raw)
In-Reply-To: <be57719e-81ed-9574-02b1-1d85efde624c@sandeen.net>

On Fri, May 04, 2018 at 01:20:42PM -0500, Eric Sandeen wrote:
> On 4/17/18 9:46 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Examine all remote xattr values of a file, not just the XFS_ATTR_ROOT
> > values.  This enables us to detect and zap corrupt user xattrs, as
> > tested by xfs/404.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Whoa.  ;)  Where'd this come from?  At first glance it seems crazy to only
> check XFS_ATTR_ROOT but then I stated digging a little...
> 
> This is essentially akin to other code we still have in the local
> case,
> 
>         /* Only check values for root security attributes */
>         if (entry->flags & XFS_ATTR_ROOT) {
>                 if (valuecheck(mp, (char *)&local->nameval[0], NULL,
>                                 local->namelen, be16_to_cpu(local->valuelen))) {
>                         do_warn(
>         _("bad security value for attribute entry %d in attr block %u, inode %" PRIu64 "\n"),
>                                 i, da_bno, ino);
>                         return -1;
>                 }
>         }
> 
> soooo this patch essentially allows valuecheck on !XFS_ATTR_ROOT attributes,
> but valuecheck says:
> 
>  * Calls will be made to xfs_mac_valid or xfs_acl_valid routines if the
>  * security attributes exist. They will be cleared if invalid.
>  * No other values will be checked. 
> 
> So, um, what's actually getting fixed?  Ah, ok:
> 
> this also allows us to simply try to /get/ the remote attribute:
> 
> rmtval_get()
> 
> and if that fails:
> 
>                 do_warn(
>         _("remote attribute get failed for entry %d, inode %" PRIu64 "\n"),
>                         i, ino);
>                 goto bad_free_out;
> 
> we zap it.
> 
> So ... uh...
> 
> I think you want to /move/ the XFS_ATTR_ROOT check before the call to valuecheck(),
> rather than removing it entirely.

Yes.  I could just make it part of the valuecheck test...

if (rmtval_get(...)) {
	do_warn(...);
	goto bad_free_out;
}

if ((entry->flags & XFS_ATTR_ROOT) &&
    valuecheck(...)) {
	do_warn(...);
	goto bad_free_out;
}

free(value);

--D

> 
> Ok, at this rate I'll have all 11 patches done by June.
> 
> -Eric
> 
> > ---
> >  repair/attr_repair.c |    3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > 
> > diff --git a/repair/attr_repair.c b/repair/attr_repair.c
> > index 8b1b8a7..bb5ab3d 100644
> > --- a/repair/attr_repair.c
> > +++ b/repair/attr_repair.c
> > @@ -537,9 +537,6 @@ process_leaf_attr_remote(
> >  		return -1;
> >  	}
> >  
> > -	if (!(entry->flags & XFS_ATTR_ROOT))
> > -		goto out;
> > -
> >  	value = malloc(be32_to_cpu(remotep->valuelen));
> >  	if (value == NULL) {
> >  		do_warn(
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-05-04 19:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-18  2:46 [PATCH 00/11] xfsprogs-4.17: xfs_repair fixes Darrick J. Wong
2018-04-18  2:46 ` [PATCH 01/11] xfs_repair: examine all remote attribute blocks Darrick J. Wong
2018-05-04 18:20   ` Eric Sandeen
2018-05-04 19:23     ` Darrick J. Wong [this message]
2018-05-23  3:15   ` [PATCH v2 " Darrick J. Wong
2018-05-23  3:47     ` Allison Henderson
2018-04-18  2:46 ` [PATCH 02/11] xfs_repair: don't leak buffer on xattr remote buf verifier error Darrick J. Wong
2018-05-04 19:16   ` Eric Sandeen
2018-04-18  2:46 ` [PATCH 03/11] xfs_repair: validate some of the log space information Darrick J. Wong
2018-05-04 19:29   ` Eric Sandeen
2018-05-04 20:25     ` Darrick J. Wong
2018-05-04 20:54       ` Eric Sandeen
2018-05-23  3:15   ` [PATCH v2 " Darrick J. Wong
2018-05-23  3:52     ` Allison Henderson
2018-04-18  2:46 ` [PATCH 04/11] xfs_repair: zap corrupt remote symlink Darrick J. Wong
2018-05-04 19:46   ` Eric Sandeen
2018-05-04 20:22     ` Darrick J. Wong
2018-04-18  2:47 ` [PATCH 05/11] xfs_repair: treat zero da btree pointers as corruption Darrick J. Wong
2018-05-04 19:59   ` Eric Sandeen
2018-04-18  2:47 ` [PATCH 06/11] xfs_repair: invalidate dirty dir buffers when we zap a directory Darrick J. Wong
2018-05-04 20:13   ` Eric Sandeen
2018-04-18  2:47 ` [PATCH 07/11] xfs_repair: only update in-core extent state after scanning full extent Darrick J. Wong
2018-05-04 21:52   ` Eric Sandeen
2018-04-18  2:47 ` [PATCH 08/11] xfs_repair: don't crash if da btree is corrupt Darrick J. Wong
2018-05-04 22:00   ` Eric Sandeen
2018-04-18  2:47 ` [PATCH 09/11] xfs_repair: don't assert if we run across a dir entry with null ino ptr Darrick J. Wong
2018-05-04 22:33   ` Eric Sandeen
2018-05-04 22:45     ` Darrick J. Wong
2018-05-08 16:07       ` Darrick J. Wong
2018-05-08 16:31   ` [PATCH v2 09/11] xfs_repair: actually fix .. entries that point to inode zero Darrick J. Wong
2018-04-18  2:47 ` [PATCH 10/11] xfs_repair: check inode nsec for obviously garbage values Darrick J. Wong
2018-05-04 22:38   ` Eric Sandeen
2018-04-18  2:47 ` [PATCH 11/11] xfs_repair: don't assert on bad '.' entry in no-modify mode Darrick J. Wong
2018-05-04 22:41   ` Eric Sandeen

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=20180504192337.GJ26569@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.net \
    /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