From patchwork Wed Mar 16 15:26:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Austin S. Hemmelgarn" X-Patchwork-Id: 8601791 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 2DEF4C0553 for ; Wed, 16 Mar 2016 15:26:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3E6982034B for ; Wed, 16 Mar 2016 15:26:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 60B5020259 for ; Wed, 16 Mar 2016 15:26:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935179AbcCPP00 (ORCPT ); Wed, 16 Mar 2016 11:26:26 -0400 Received: from mail-qg0-f51.google.com ([209.85.192.51]:35380 "EHLO mail-qg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935174AbcCPP0Z (ORCPT ); Wed, 16 Mar 2016 11:26:25 -0400 Received: by mail-qg0-f51.google.com with SMTP id y89so46212684qge.2 for ; Wed, 16 Mar 2016 08:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=w6cL5hbqthe7slmXU4VC0S3NYqYFkZPL4GOWiDaKUi0=; b=dqwNuvK/1EJh8GkI0G7i++mirNshOYLEIBXBd9S65iMPsqqAPDukLKGa/1sfAucDFM fR/pykAKdDG0UtIML0HJPlhjPKrhTxCkVck7nkAXWu9bPrxTopI5r1Oj0ZMYIKZ6m5R4 DwK1qu5s8Xj2OfNH5ilEuHq8DYcLE5twCluEuVdYJB4ztdFK7xEbm5IBRHxeHe0JAviQ ZwZhAKiiD+jNq/CH3XFsckUvF7KF+6TpXBE9L0VlhWBb2RlGTM1VM2BNwPwGIvVxrMoV wlUS36d8EGej5yeZ4p/yrcO0UOtDy17KwgvbFuLYSG9GR6Ay7+nSDdsb+ejzVzQsu8BO l6VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=w6cL5hbqthe7slmXU4VC0S3NYqYFkZPL4GOWiDaKUi0=; b=ceZGDddJA+xO/qVLsU6aar64zpo6QjlsFyOalDTBS26tmtNHO8C7Ikq0Q/Y1fGVkPm 79MpYR4l0GJ9dTnvy/qYRB/sjTv5Flpk++74XGp36XZ+cDd0ZbDV4tum+68Jh3/cQeCe LYXhaWbi6JB7WHjBHg1GVo6UcA5LYbuvORy5cL7CuvydU1KFobKRW43KE2pCNR3EEJNR 9laxY48Ao6ds90aIQoeF14jzWxEaTks+5Vrs57JQBSFfS3VeUkWS3OEEYG1OsnaYQoen LIQKgasqih/9UVXYON6U5ZkT9bmhPsPKZMYHo89Cpuy5KZgsdcSclej+v+F3wsPTRMNi 8NtQ== X-Gm-Message-State: AD7BkJIIBFAUfSuVe5+8y4Wk6rWtlwE21/p/vdt+1k2wx1Wug6yYoyiDqcOvT2Swydl+fw== X-Received: by 10.140.94.69 with SMTP id f63mr6259127qge.0.1458141984868; Wed, 16 Mar 2016 08:26:24 -0700 (PDT) Received: from wild-karde.localdomain (rrcs-70-62-41-24.central.biz.rr.com. [70.62.41.24]) by smtp.googlemail.com with ESMTPSA id p80sm1703243qge.0.2016.03.16.08.26.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Mar 2016 08:26:24 -0700 (PDT) Received: by wild-karde.localdomain (Postfix, from userid 1000) id DFC951A45208; Wed, 16 Mar 2016 11:26:22 -0400 (EDT) From: "Austin S. Hemmelgarn" To: linux-btrfs@vger.kernel.org Cc: "Austin S. Hemmelgarn" Subject: [PATCH] btrfs-progs: add stat check in open_ctree_fs_info Date: Wed, 16 Mar 2016 11:26:11 -0400 Message-Id: <1458141971-56355-1-git-send-email-ahferroin7@gmail.com> X-Mailer: git-send-email 2.7.3 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Currently, open_ctree_fs_info will open whatever path you pass it and try to interpret it as a BTRFS filesystem. While this is not nessecarily dangerous (except possibly if done on a character device), it does result in some rather cryptic and non-sensical error messages when trying to run certain commands in ways they weren't intended to be run. Add a check using stat(2) to verify that the path we've been passed is in fact a regular file or a block device. This causes the following commands to provide a helpful error message when run on a FIFO, directory, character device, or socket: * btrfs check * btrfs restore * btrfs-image * btrfs-find-root * btrfs-debug-tree Signed-off-by: Austin S. Hemmelgarn --- This has been build and runtime tested on an x86-64 system with glibc. It has been build tested on x86-64 with uclibc. It has not been tested on Android or with musl, although it should work there also. There are other tools that have similarly bad behavior when called incorrectly (btrfs rescue immediately comes to mind), but they don't use open_ctree_fs_info, so this doesn't affect them. I may do followup patches to fix those too if I have the time. open_ctree_fs_info is also used in cmds-filesystem.c, although I'm not at all sure what exactly is going on there, and btrfs filesystem appears from my testing to behave exactly the same with this change, so I don't think this will have any effect on any of the btrfs filesystem commands. disk-io.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/disk-io.c b/disk-io.c index e520d80..d35153d 100644 --- a/disk-io.c +++ b/disk-io.c @@ -1310,6 +1310,13 @@ struct btrfs_fs_info *open_ctree_fs_info(const char *filename, int fp; struct btrfs_fs_info *info; int oflags = O_CREAT | O_RDWR; + struct stat sb; + + stat(filename, &sb); + if (!(((sb.st_mode & S_IFMT) == S_IFREG) || ((sb.st_mode & S_IFMT) == S_IFBLK))) { + fprintf (stderr, "%s is not a regular file or block device\n", filename); + return NULL; + } if (!(flags & OPEN_CTREE_WRITES)) oflags = O_RDONLY;