Message ID | 20181008233952.20965-1-nicholas.clark@gmail.com |
---|---|
Headers | show
Return-Path: <linux-ext4-owner@vger.kernel.org> X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=<UNKNOWN>) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="FfL0lZZz"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42TcKZ20WXz9vZs for <patchwork-incoming@ozlabs.org>; Tue, 9 Oct 2018 10:40:01 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725808AbeJIGyI (ORCPT <rfc822;patchwork-incoming@ozlabs.org>); Tue, 9 Oct 2018 02:54:08 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:39333 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725759AbeJIGyI (ORCPT <rfc822; linux-ext4@vger.kernel.org>); Tue, 9 Oct 2018 02:54:08 -0400 Received: by mail-io1-f66.google.com with SMTP id z16-v6so17190795iol.6 for <linux-ext4@vger.kernel.org>; Mon, 08 Oct 2018 16:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=lv+dzXqS2joKpLc8LEHaoc+chirYTncWA2NlD1vqErA=; b=FfL0lZZz+6OVe88llhlkP9mV1rRhKOacCGIQ9jAH3le344sQmhqBAXvWI28ozQZwJG 8p8p/X2wcMn0WzsY+q+uXp3lzX2/pFZ8HpMsO8UpIqK+hX/XdpFpA6yM2gIJC3pAdsFG mw81Ysj4v8sugI3pDY1OE6AOLOTqSDx6kwcBb1TI4iaohyOYg0KwWUC0ZmwRlXD3qyp0 PF414NYBVuozpS6kEAqm6LmEKbT+pROGzQbvDOvo42csYs7vm0Wnor7qrE78wRCF07pt OjtQwE6Ad56Zb8Ek1A8QgsxXUnR3JS+ZPah0cqxythtQ5TP5lrOSs3eauaRr0KFqusIr tYFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=lv+dzXqS2joKpLc8LEHaoc+chirYTncWA2NlD1vqErA=; b=MYEWf1XCf1Twp/dYeZrWLsAyNciQdaFSx4Vub3F+r+2VyM28K8ZORwWLNr/GE6gSo3 eyLBSdWmYMI82UjhEOWsxkAvOXrTaNuD/TwWJ7IUDE5OGB1ktSp9wnxGagSzVGKw9nkB d0WhufJAX35PSq81yDIr46D7IrNgCBQq6V+4gHdtqmgHcLXMfBtCWFmdRdfwW1eOJBjD iefo2GmKCcvOuew0011B2aykk6+u4LF8WcH+DmC7WtWKyPlvSVn8/03diS99F0HAlzr2 IdC55BkbTKs0QdV8g2r0COTmLWwShnoKFNG/hwrIGyLORpnLY+LZuJm/Yubvkr5ysg/O Uzhw== X-Gm-Message-State: ABuFfohLrWJJc5hf/quJcHYpgZolsiunsVXes0j6f6k5ArX4f8bJDSLK sXHHoE5FwNPuzDoiJuy69S87M0g6 X-Google-Smtp-Source: ACcGV620CnG3MNEsxdNMRQIiLoU5LQa7lzIg3FS9nRY8CIEXPewy3NyuKKLkJvq9li7UmJOjsBVgvw== X-Received: by 2002:a6b:8d8a:: with SMTP id p132-v6mr16673947iod.240.1539041999478; Mon, 08 Oct 2018 16:39:59 -0700 (PDT) Received: from localhost.localdomain.localdomain (97-122-193-216.hlrn.qwest.net. [97.122.193.216]) by smtp.gmail.com with ESMTPSA id v26-v6sm5735119iog.12.2018.10.08.16.39.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Oct 2018 16:39:58 -0700 (PDT) From: nicholas.clark@gmail.com To: linux-ext4@vger.kernel.org Cc: Nick Clark <nicholas.clark@gmail.com> Subject: [PATCH 0/2] e2fsprogs: fuse2fs bugfix and new 'fakeroot' feature Date: Mon, 8 Oct 2018 17:39:50 -0600 Message-Id: <20181008233952.20965-1-nicholas.clark@gmail.com> X-Mailer: git-send-email 2.17.1 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: <linux-ext4.vger.kernel.org> X-Mailing-List: linux-ext4@vger.kernel.org |
Series |
e2fsprogs: fuse2fs bugfix and new 'fakeroot' feature
|
expand
|
From: Nick Clark <nicholas.clark@gmail.com> Hi all, I wrote a couple of patches for fuse2fs (from the e2fsprogs collection). One is a minor bugfix to the displayed name in the mount command's output, and the other is a new 'fakeroot' mount option, as described below. When building cross-compiled Linux systems (for use on routers, consumer devices, etc), it's often necessary to build rootfs filesystem images. This commit adds a new 'fakeroot' mount option that gives a user full control over the mounted filesystem, within the confines of FUSE. When used, the new option allows treats allowed users as uid 0 for the purposes of permission checks (within the mounted filesystem). This allows the owner of a .img file to mount the file and make whatever changes they want to any files inside of the image. If the option is left disabled at mount-time, fuse2fs acts the same as before - only root can edit "root"-owned files inside of the image. But when enabled, fuse2fs becomes a powerful tool to build/modify filesystem images. What do you all think? -Nick Nicholas Clark (2): Fuse2fs: fix 'mount' entry in some cases. Fuse2fs: add fakeroot option. acinclude.m4 | 47 ++++++++++++++++ configure | 134 ++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 4 ++ lib/config.h.in | 6 +++ misc/fuse2fs.1.in | 3 ++ misc/fuse2fs.c | 31 ++++++++--- 6 files changed, 217 insertions(+), 8 deletions(-)