All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] fs: apply permissions late
Date: Tue, 30 Oct 2018 21:23:31 +0100	[thread overview]
Message-ID: <20181030202331.GI28575@scaer> (raw)
In-Reply-To: <CANQCQpa3y_Qs7H9aB1Y7fpW9G=V2Dr2yqM9WihrQBuqUbPoEhA@mail.gmail.com>

Matt, All,

On 2018-10-27 08:14 -0500, Matthew Weber spake thusly:
> On Sat, Oct 27, 2018 at 2:46 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >
> > The combination of fakeroot, tar, and capabilities is broken, because
> > fakeroot currently badly handles capabilities, which are currently
> > simply ignored.
> >
> > As described in #11216, asking tar to explicitly store and restore
> > capabilities ends up with a failling build, when tar actually tries to
> failling -> failing
> 
> > restore the capabilities. Adding support for capabilities to fakeroot
> > (by adding host-libcap as dependency) does not fix the problem.
> >
> > Capabilities are stored in the extended attribute security.capabilty.
> Capabilities are stored in the extended attribute security capability.

Thanks for the fixes! :-)

Yet, the extended attribute is really named "security.capabilty" (i.e.
with a dot in-between the two words): https://linux.die.net/man/7/capabilities

    Since kernel 2.6.24, the kernel supports associating capability sets
    [...] stored in an extended attribute (see setxattr(2)) named
    security.capability.o

Regards,
Yann E. MORIN.

> > It turns out that tar does have special handling when extracting and
> > restoring that extended attribute, and that fails miserably when running
> > under fakeroot...
> >
> > We fix that by offloading the permissions handling down to individual
> > filesystems.
> >
> > This needs a split of the makedevs call, with the current and first one
> > now only responsible for creating the pseudo devices, while the new,
> > second call does only set the permissions.
> >
> > Fixes: #11216
> >
> > This changes the order of steps, and post-fakeroot scripts are now
> > called before the permissions are set. This could mean breaking existing
> > setups, but more probably, this woudl sovle some, where files created in
> setups, but more probably, this would solve some, where files created in
> 
> > post-fakeroot scripts can now see their permissions appropriately set.
> >
> > This also slightly breaks the idea behind the intermediate image, which
> > was supposed to gather all actions common to all filesystems, so that
> > they are not repeated. Still, most actions are still created only once,
> > and moving just this is purely a practical and pragmatic workaround.
> >
> > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> > Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
> > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
> 
> Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> 
> > ---
> >  fs/common.mk | 17 +++++++++++------
> >  1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/common.mk b/fs/common.mk
> > index 453da6010a..569e5d60c5 100644
> > --- a/fs/common.mk
> > +++ b/fs/common.mk
> > @@ -29,8 +29,8 @@
> >
> >  FS_DIR = $(BUILD_DIR)/buildroot-fs
> >  FULL_DEVICE_TABLE = $(FS_DIR)/device_table.txt
> > -ROOTFS_DEVICE_TABLES = $(call qstrip,$(BR2_ROOTFS_DEVICE_TABLE) \
> > -       $(BR2_ROOTFS_STATIC_DEVICE_TABLE))
> > +ROOTFS_PERMISSION_TABLES = $(call qstrip,$(BR2_ROOTFS_DEVICE_TABLE))
> > +ROOTFS_STATIC_DEVICE_TABLES = $(call qstrip,$(BR2_ROOTFS_STATIC_DEVICE_TABLE))
> >  USERS_TABLE = $(FS_DIR)/users_table.txt
> >  ROOTFS_USERS_TABLES = $(call qstrip,$(BR2_ROOTFS_USERS_TABLES))
> >
> > @@ -81,14 +81,13 @@ ifneq ($(ROOTFS_USERS_TABLES),)
> >         cat $(ROOTFS_USERS_TABLES) >> $(USERS_TABLE)
> >  endif
> >         PATH=$(BR_PATH) $(TOPDIR)/support/scripts/mkusers $(USERS_TABLE) $(TARGET_DIR) >> $(FAKEROOT_SCRIPT)
> > -ifneq ($(ROOTFS_DEVICE_TABLES),)
> > -       cat $(ROOTFS_DEVICE_TABLES) > $(FULL_DEVICE_TABLE)
> > +ifneq ($(ROOTFS_STATIC_DEVICE_TABLES),)
> > +       cat $(ROOTFS_STATIC_DEVICE_TABLES) > $(FULL_DEVICE_TABLE)
> >  ifeq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)
> >         $(call PRINTF,$(PACKAGES_DEVICES_TABLE)) >> $(FULL_DEVICE_TABLE)
> >  endif
> > -endif
> > -       $(call PRINTF,$(PACKAGES_PERMISSIONS_TABLE)) >> $(FULL_DEVICE_TABLE)
> >         echo "$(HOST_DIR)/bin/makedevs -d $(FULL_DEVICE_TABLE) $(TARGET_DIR)" >> $(FAKEROOT_SCRIPT)
> > +endif
> >         $(foreach s,$(call qstrip,$(BR2_ROOTFS_POST_FAKEROOT_SCRIPT)),\
> >                 echo "echo '$(TERM_BOLD)>>>   Executing fakeroot script $(s)$(TERM_RESET)'" >> $(FAKEROOT_SCRIPT); \
> >                 echo $(EXTRA_ENV) $(s) $(TARGET_DIR) $(BR2_ROOTFS_POST_SCRIPT_ARGS) >> $(FAKEROOT_SCRIPT)$(sep))
> > @@ -108,6 +107,7 @@ define inner-rootfs
> >
> >  ROOTFS_$(2)_DIR = $$(FS_DIR)/$(1)
> >  ROOTFS_$(2)_TARGET_DIR = $$(ROOTFS_$(2)_DIR)/target
> > +ROOTFS_$(2)_PERMISSION_TABLE = $$(ROOTFS_$(2)_DIR)/permissions.txt
> >
> >  ROOTFS_$(2)_DEPENDENCIES += rootfs-common
> >
> > @@ -149,6 +149,11 @@ $$(BINARIES_DIR)/rootfs.$(1): $$(ROOTFS_$(2)_DEPENDENCIES)
> >         echo '#!/bin/sh' > $$(FAKEROOT_SCRIPT)
> >         echo "set -e" >> $$(FAKEROOT_SCRIPT)
> >         $$(call PRINTF,$$(ROOTFS_COMMON_UNTAR_CMD)) >> $$(FAKEROOT_SCRIPT)
> > +ifneq ($$(ROOTFS_PERMISSION_TABLES),)
> > +       cat $$(ROOTFS_PERMISSION_TABLES) > $$(ROOTFS_$(2)_PERMISSION_TABLE)
> > +endif
> > +       $$(call PRINTF,$$(PACKAGES_PERMISSIONS_TABLE)) >> $$(ROOTFS_$(2)_PERMISSION_TABLE)
> 
> If a package duplicates an entry and is below a user provided rootfs
> permissions table similar item, I assume makedev uses the last entry
> as the one to set?  If so, should the two lines above be flipped so
> the "user provided" can always fixup/override the package default?
> 
> Matt

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-10-30 20:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-27  7:45 [Buildroot] [PATCH 0/3] fs: fix and better handle capabilities Yann E. MORIN
2018-10-27  7:45 ` [Buildroot] [PATCH 1/3] fs: apply permissions late Yann E. MORIN
2018-10-27 13:14   ` Matthew Weber
2018-10-30 20:23     ` Yann E. MORIN [this message]
2018-10-31  1:18       ` Matthew Weber
2018-10-31 21:49         ` Yann E. MORIN
2018-11-02 20:29           ` Matthew Weber
2018-11-03 13:38   ` Thomas Petazzoni
2018-11-10 17:17     ` Yann E. MORIN
2018-11-07 23:43   ` Arnout Vandecappelle
2018-11-09 20:13     ` Arnout Vandecappelle
2018-11-10 17:08       ` Yann E. MORIN
2018-11-10 17:57     ` Yann E. MORIN
2018-11-11 16:02       ` Arnout Vandecappelle
2018-11-11 16:44         ` Yann E. MORIN
2018-11-11 20:03         ` Peter Korsgaard
2018-11-11 20:02       ` Peter Korsgaard
2018-11-12  8:17         ` Yann E. MORIN
2018-11-08 22:58   ` Peter Korsgaard
2018-11-09  8:55     ` Peter Korsgaard
2018-11-10 17:07     ` Yann E. MORIN
2018-10-27  7:45 ` [Buildroot] [PATCH 2/3] fs: be oblivious of pre-existing xattrs Yann E. MORIN
2018-11-02 20:31   ` Matthew Weber
2018-10-27  7:46 ` [Buildroot] [PATCH 3/3] fs: fix condition to create static devices Yann E. MORIN
2018-11-02 20:34   ` Matthew Weber

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=20181030202331.GI28575@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.