linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Jan Tulak <jtulak@redhat.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2 v5] fsck.xfs: allow forced repairs using xfs_repair
Date: Thu, 22 Mar 2018 20:42:51 -0700	[thread overview]
Message-ID: <20180323034251.GI4818@magnolia> (raw)
In-Reply-To: <f68aab96-7a08-26ee-2b9c-dfe291689506@sandeen.net>

On Thu, Mar 22, 2018 at 10:29:27PM -0500, Eric Sandeen wrote:
> 
> 
> On 3/22/18 10:25 PM, Darrick J. Wong wrote:
> >> It make sense to check that it's available before running it, but I think
> >> hardcoding paths runs the risk of missing it if it's somewhere unique.
> 
> > OTOH hardcoding the path (since we control where xfs_repair gets
> > installed) means that we avoid the "someone poisoned PATH" attack.  I'm
> > not sure I buy that argument since if you have root access you probably
> > can just bind mount a garbage atop /sbin/xfs_repair, but eh.
> 
> But this is the initramfs, right?  Do we really have any idea where things
> land?  Do initramfs paths follow the installed system paths?  (maybe?)

They land wherever the initramfs construction script puts them, though
at least on Debian the binaries are usually put in the same places as
they are on the rootfs.  Not sure about dracut. :)

--D

> -Eric
> --
> 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-03-23  3:42 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 15:05 [PATCH] fsck.xfs: allow forced repairs using xfs_repair Jan Tulak
2018-03-05 21:56 ` Dave Chinner
2018-03-05 22:06   ` Eric Sandeen
2018-03-05 22:20     ` Darrick J. Wong
2018-03-05 22:31     ` Dave Chinner
2018-03-05 23:33       ` Eric Sandeen
2018-03-06 11:51         ` Jan Tulak
2018-03-06 21:39           ` Dave Chinner
2018-03-08 10:57             ` Jan Tulak
2018-03-08 16:28               ` Darrick J. Wong
2018-03-08 22:36                 ` Dave Chinner
2018-03-14 13:51                   ` Jan Tulak
2018-03-14 15:25                     ` Darrick J. Wong
2018-03-14 21:10                       ` Dave Chinner
2018-03-15 17:01                       ` Jan Tulak
2018-03-08 23:28               ` Eric Sandeen
2018-03-14 13:30                 ` Jan Tulak
2018-03-14 15:19                   ` Eric Sandeen
2018-03-15 11:16                     ` Jan Tulak
2018-03-15 22:19                       ` Dave Chinner
2018-03-15 17:45 ` [PATCH 1/2] xfs_repair: add flag -e to detect corrected errors Jan Tulak
2018-03-15 17:45   ` [PATCH 2/2 v1] fsck.xfs: allow forced repairs using xfs_repair Jan Tulak
2018-03-15 17:47     ` [PATCH 2/2 v2] " Jan Tulak
2018-03-15 17:50       ` [PATCH 2/2] " Jan Tulak
2018-03-15 18:11         ` Darrick J. Wong
2018-03-15 18:22           ` Jan Tulak
2018-03-15 18:28         ` [PATCH 2/2 v4] " Jan Tulak
2018-03-15 18:49           ` Darrick J. Wong
2018-03-16 10:19             ` Jan Tulak
2018-03-16 15:39               ` Darrick J. Wong
2018-03-16 17:07           ` [PATCH 2/2 v5] " Jan Tulak
2018-03-23  2:37             ` Eric Sandeen
2018-03-23  3:25               ` Darrick J. Wong
2018-03-23  3:29                 ` Eric Sandeen
2018-03-23  3:42                   ` Darrick J. Wong [this message]
2018-03-23 14:00                     ` Jan Tulak
2018-03-23 14:14               ` Jan Tulak
2018-03-23 14:33             ` [PATCH 2/2 v6] " Jan Tulak
2022-09-28  5:28               ` Darrick J. Wong
2022-09-29  8:31                 ` Carlos Maiolino
2018-03-15 18:03   ` [PATCH 1/2] xfs_repair: add flag -e to detect corrected errors Darrick J. Wong
2018-03-15 18:23   ` [PATCH 1/2 v2] " Jan Tulak
2018-03-15 18:44     ` Darrick J. Wong
2018-03-23  1:57     ` Eric Sandeen
2018-03-23  9:24       ` Jan Tulak
2018-03-23 14:32     ` [PATCH 1/2 v3] xfs_repair: add flag -e to modify exit code for " Jan Tulak

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=20180323034251.GI4818@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=jtulak@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).