[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[gustavo.zacarias at free-electrons.com]

From: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>

This series adds file capability & xattr support for target filesystems.

It's done by enabling the latest fakeroot support for it, which requires
a attr-enabled host-libcap, which in turn needs a host-attr package to
match as well.

It wasn't made optional since the time delta for a non-attr versus
attr-enabled host-fakeroot and it's dependencies is just 5 seconds on a
quad-core i5 - hardly worth the additional complexities.

TODO:
This still needs matching makedevs support, or alternatively a separate
option and data file to handle this functionality. It would probably be
It's probably better to use this functionality with a separate tool and
data file(s) to avoid clutternig the device table too much (ostensibly
ACL support could be added as well).

Also not all target filesystems support extended attributes.

Change for v2:
 Use install-dev for host-attr installation.

Gustavo Zacarias (4):
  attr: add host variant
  attr: cleanup pointless indentation
  libcap: enable extended attribute support
  fakeroot: enable capability support

 package/attr/attr.mk         | 20 +++++++++++++-------
 package/fakeroot/fakeroot.mk |  8 +-------
 package/libcap/libcap.mk     | 10 +++++-----
 3 files changed, 19 insertions(+), 19 deletions(-)

-- 
2.4.10

[Buildroot] [PATCH v2 1/4] attr: add host variant

[gustavo.zacarias at free-electrons.com]

From: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>

This is required for host-libcap for extended attributes support, which
leads to capabilities support as well.

Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
---
 package/attr/attr.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/attr/attr.mk b/package/attr/attr.mk
index a66891b..e9963ba 100644
--- a/package/attr/attr.mk
+++ b/package/attr/attr.mk
@@ -26,6 +26,11 @@ ATTR_INSTALL_TARGET_OPTS = 			\
 	exec_prefix=$(TARGET_DIR)/usr 		\
 	install install-lib
 
+HOST_ATTR_INSTALL_OPTS = \
+	prefix=$(HOST_DIR)/usr \
+	exec_prefix=$(HOST_DIR)/usr \
+	install-dev install-lib
+
 # The libdir variable in libattr.la is empty, so let's fix it. This is
 # probably due to attr not using automake, and not doing fully the
 # right thing with libtool.
@@ -37,3 +42,4 @@ endef
 ATTR_POST_INSTALL_STAGING_HOOKS += ATTR_FIX_LIBTOOL_LA_LIBDIR
 
 $(eval $(autotools-package))
+$(eval $(host-autotools-package))
-- 
2.4.10

[Buildroot] [PATCH v2 2/4] attr: cleanup pointless indentation

[gustavo.zacarias at free-electrons.com]

From: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>

Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
---
 package/attr/attr.mk | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/package/attr/attr.mk b/package/attr/attr.mk
index e9963ba..3db66cb 100644
--- a/package/attr/attr.mk
+++ b/package/attr/attr.mk
@@ -15,15 +15,15 @@ ATTR_LICENSE_FILES = doc/COPYING doc/COPYING.LGPL
 # While the configuration system uses autoconf, the Makefiles are
 # hand-written and do not use automake. Therefore, we have to hack
 # around their deficiencies by passing installation paths.
-ATTR_INSTALL_STAGING_OPTS = 			\
-	prefix=$(STAGING_DIR)/usr 		\
-	exec_prefix=$(STAGING_DIR)/usr 		\
-	PKG_DEVLIB_DIR=$(STAGING_DIR)/usr/lib 	\
+ATTR_INSTALL_STAGING_OPTS = \
+	prefix=$(STAGING_DIR)/usr \
+	exec_prefix=$(STAGING_DIR)/usr \
+	PKG_DEVLIB_DIR=$(STAGING_DIR)/usr/lib \
 	install-dev install-lib
 
-ATTR_INSTALL_TARGET_OPTS = 			\
-	prefix=$(TARGET_DIR)/usr 		\
-	exec_prefix=$(TARGET_DIR)/usr 		\
+ATTR_INSTALL_TARGET_OPTS = \
+	prefix=$(TARGET_DIR)/usr \
+	exec_prefix=$(TARGET_DIR)/usr \
 	install install-lib
 
 HOST_ATTR_INSTALL_OPTS = \
-- 
2.4.10

[Buildroot] [PATCH v2 3/4] libcap: enable extended attribute support

[gustavo.zacarias at free-electrons.com]

From: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>

This is required for capability support in files, via fakeroot.

Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
---
 package/libcap/libcap.mk | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/package/libcap/libcap.mk b/package/libcap/libcap.mk
index 54844f8..252c4bb 100644
--- a/package/libcap/libcap.mk
+++ b/package/libcap/libcap.mk
@@ -20,8 +20,7 @@ else
 LIBCAP_HAVE_LIBATTR = no
 endif
 
-# we don't have host-attr
-HOST_LIBCAP_DEPENDENCIES =
+HOST_LIBCAP_DEPENDENCIES = host-attr
 
 ifeq ($(BR2_STATIC_LIBS),y)
 LIBCAP_MAKE_TARGET = libcap.a
@@ -67,12 +66,13 @@ define LIBCAP_INSTALL_TARGET_CMDS
 endef
 
 define HOST_LIBCAP_BUILD_CMDS
-	$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D) LIBATTR=no
+	$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)\
+		LIBATTR=yes RAISE_SETFCAP=no
 endef
 
 define HOST_LIBCAP_INSTALL_CMDS
-	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) LIBATTR=no DESTDIR=$(HOST_DIR) \
-		prefix=/usr lib=lib install
+	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(HOST_DIR) \
+		LIBATTR=yes RAISE_SETFCAP=no prefix=/usr lib=lib install
 endef
 
 $(eval $(generic-package))
-- 
2.4.10

[Buildroot] [PATCH v2 4/4] fakeroot: enable capability support

[gustavo.zacarias at free-electrons.com]

From: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>

Enable file capability support, this still requires fakeroot script
(makedev) support.

Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
---
 package/fakeroot/fakeroot.mk | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/package/fakeroot/fakeroot.mk b/package/fakeroot/fakeroot.mk
index 168cd13..06f1a73 100644
--- a/package/fakeroot/fakeroot.mk
+++ b/package/fakeroot/fakeroot.mk
@@ -7,13 +7,7 @@
 FAKEROOT_VERSION = 1.20.2
 FAKEROOT_SOURCE = fakeroot_$(FAKEROOT_VERSION).orig.tar.bz2
 FAKEROOT_SITE = http://snapshot.debian.org/archive/debian/20141005T221953Z/pool/main/f/fakeroot
-# Force capabilities detection off
-# For now these are process capabilities (faked) rather than file
-# so they're of no real use
-HOST_FAKEROOT_CONF_ENV = \
-	ac_cv_header_sys_capability_h=no \
-	ac_cv_func_capset=no
-
+FAKEROOT_DEPENDENCIES = host-libcap
 FAKEROOT_LICENSE = GPLv3+
 FAKEROOT_LICENSE_FILES = COPYING
 
-- 
2.4.10

[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[Thomas Petazzoni]

Hello,

On Wed, 24 Feb 2016 11:26:28 -0300, gustavo.zacarias at free-electrons.com
wrote:

> It's done by enabling the latest fakeroot support for it, which requires
> a attr-enabled host-libcap, which in turn needs a host-attr package to
> match as well.
> 
> It wasn't made optional since the time delta for a non-attr versus
> attr-enabled host-fakeroot and it's dependencies is just 5 seconds on a
> quad-core i5 - hardly worth the additional complexities.

Even if it's not that long, I'm not super happy with adding some more
packages to our default build, for a use case that is normally pretty
limited.

> TODO:
> This still needs matching makedevs support, or alternatively a separate
> option and data file to handle this functionality. It would probably be
> It's probably better to use this functionality with a separate tool and
> data file(s) to avoid clutternig the device table too much (ostensibly
> ACL support could be added as well).

So, if you think that specifying the capabilities or extended
attributes should be done via a separate data file, then it means we
will have a new option to specify this data file, and we could
therefore only bring the additional host-fakeroot dependencies only
when this option is enabled, no?

> Also not all target filesystems support extended attributes.

And possibly the above option should be made visible only when the
underlying filesystem supports extended attributes.

What do you think?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[Gustavo Zacarias]

On 25/02/16 17:50, Thomas Petazzoni wrote:

> So, if you think that specifying the capabilities or extended
> attributes should be done via a separate data file, then it means we
> will have a new option to specify this data file, and we could
> therefore only bring the additional host-fakeroot dependencies only
> when this option is enabled, no?

Hi.
This is a RFC mostly since it's not complete, although it can be 
commited as-is it's not usable directly without tweaking the fakeroot 
script (which isn't exposed functionality at the moment).
We can extend makedevs syntax/tool, but i believe it will be terribly 
messy for scenarios where multiple XATTRs are desired, more so if we 
eventually add ACL support to this.

>> Also not all target filesystems support extended attributes.
>
> And possibly the above option should be made visible only when the
> underlying filesystem supports extended attributes.
>
> What do you think?
>
> Thomas

Well, i was hoping for feedback, let's see other opinions.
Enabling capabilities/xattrs/acls might be an option in target 
filesystem where people can then add the respective file(s) describing 
them, hence making it optional. If it were in makedevs it could be an 
option as well but would pollute things quite a bit.
Might be worth adding tar acl/xattr support as well, rigth now squashfs 
and maybe ubifs are the only filesystem targets enabled for this.

Regards.

[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[Thomas Petazzoni]

Hello,

On Thu, 25 Feb 2016 18:00:37 -0300, Gustavo Zacarias wrote:

> This is a RFC mostly since it's not complete, although it can be 
> commited as-is it's not usable directly without tweaking the fakeroot 
> script (which isn't exposed functionality at the moment).
> We can extend makedevs syntax/tool, but i believe it will be terribly 
> messy for scenarios where multiple XATTRs are desired, more so if we 
> eventually add ACL support to this.

Agreed. On the other hand, it's somewhat annoying to have two separate
data files / mechanisms to describe the "properties" of the
files/directories installed in the root filesystem.

Can we imagine an extension to the makedevs syntax where you could give
some additional properties for a given file, as following lines, e.g:

/usr/bin/foo f 755 0 0 - - - - -
|XATTR blabla extended attribute
|XATTR blabla extended attribute
|ACL blabla ACL

Or something like this?

> Well, i was hoping for feedback, let's see other opinions.
> Enabling capabilities/xattrs/acls might be an option in target 
> filesystem where people can then add the respective file(s) describing 
> them, hence making it optional. If it were in makedevs it could be an 
> option as well but would pollute things quite a bit.

Yes, if we make it part of makedevs, then having an option would be a
bit weird, but still reasonable since this stuff is pretty advanced, so
people who need that quite certainly know what they are doing.

> Might be worth adding tar acl/xattr support as well, rigth now squashfs 
> and maybe ubifs are the only filesystem targets enabled for this.

Right. This is IMO a good reason to make this optional. makedevs could
have an option to accept (or not) the extended properties, and then if
we have not enabled xattr/capability in Buildroot, this option is not
passed, which guarantees that makedevs will bail out if an extended
property is used.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[Gustavo Zacarias]

On 25/02/16 18:10, Thomas Petazzoni wrote:

> Hello,
>
> On Thu, 25 Feb 2016 18:00:37 -0300, Gustavo Zacarias wrote:
>
>> This is a RFC mostly since it's not complete, although it can be
>> commited as-is it's not usable directly without tweaking the fakeroot
>> script (which isn't exposed functionality at the moment).
>> We can extend makedevs syntax/tool, but i believe it will be terribly
>> messy for scenarios where multiple XATTRs are desired, more so if we
>> eventually add ACL support to this.
>
> Agreed. On the other hand, it's somewhat annoying to have two separate
> data files / mechanisms to describe the "properties" of the
> files/directories installed in the root filesystem.
>
> Can we imagine an extension to the makedevs syntax where you could give
> some additional properties for a given file, as following lines, e.g:
>
> /usr/bin/foo f 755 0 0 - - - - -
> |XATTR blabla extended attribute
> |XATTR blabla extended attribute
> |ACL blabla ACL
>
> Or something like this?

My only concern with extending the format to multi lines is that the 
data file will likely be incompatible with previous versions of makedevs.

> Yes, if we make it part of makedevs, then having an option would be a
> bit weird, but still reasonable since this stuff is pretty advanced, so
> people who need that quite certainly know what they are doing.

I'd go for homogeneous syntax in makedevs if that's the chosen way, just 
make it skip those ops when it's not enabled.

> Right. This is IMO a good reason to make this optional. makedevs could
> have an option to accept (or not) the extended properties, and then if
> we have not enabled xattr/capability in Buildroot, this option is not
> passed, which guarantees that makedevs will bail out if an extended
> property is used.

Might be worth CCing rockwellcollins guys that are working in selinux, 
they're definitely interested in this since selinux loves xattrs.
Regards.

[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[Thomas Petazzoni]

Gustavo,

On Thu, 25 Feb 2016 18:29:43 -0300, Gustavo Zacarias wrote:

> > Can we imagine an extension to the makedevs syntax where you could give
> > some additional properties for a given file, as following lines, e.g:
> >
> > /usr/bin/foo f 755 0 0 - - - - -
> > |XATTR blabla extended attribute
> > |XATTR blabla extended attribute
> > |ACL blabla ACL
> >
> > Or something like this?
> 
> My only concern with extending the format to multi lines is that the 
> data file will likely be incompatible with previous versions of makedevs.

Indeed. But is this really a concern? makedevs is built by Buildroot,
so we are sure which version is being used, right?

> > Yes, if we make it part of makedevs, then having an option would be a
> > bit weird, but still reasonable since this stuff is pretty advanced, so
> > people who need that quite certainly know what they are doing.
> 
> I'd go for homogeneous syntax in makedevs if that's the chosen way, just 
> make it skip those ops when it's not enabled.

OK.

> > Right. This is IMO a good reason to make this optional. makedevs could
> > have an option to accept (or not) the extended properties, and then if
> > we have not enabled xattr/capability in Buildroot, this option is not
> > passed, which guarantees that makedevs will bail out if an extended
> > property is used.
> 
> Might be worth CCing rockwellcollins guys that are working in selinux, 
> they're definitely interested in this since selinux loves xattrs.

Seems like a good idea. Can you do that when you post your next
patches? Or maybe you can send a short summary of an initial proposal,
and Cc them?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 0/4] Add file capability/xattr support

[Thomas Petazzoni]

Gustavo,

On Wed, 24 Feb 2016 11:26:28 -0300, gustavo.zacarias at free-electrons.com
wrote:

> Gustavo Zacarias (4):
>   attr: add host variant
>   attr: cleanup pointless indentation
>   libcap: enable extended attribute support

In order to help and reduce your patch back log, I've applied those
three patches.

>   fakeroot: enable capability support

I'm marking this one as RFC in Patchwork, so that work on making it
optional, and a way of defining the xattr/capabilities is implemented.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com