From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 0/4] Add file capability/xattr support
Date: Thu, 25 Feb 2016 22:10:04 +0100 [thread overview]
Message-ID: <20160225221004.26bb337b@free-electrons.com> (raw)
In-Reply-To: <56CF6B75.10604@free-electrons.com>
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
next prev parent reply other threads:[~2016-02-25 21:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 14:26 [Buildroot] [PATCH v2 0/4] Add file capability/xattr support gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 1/4] attr: add host variant gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 2/4] attr: cleanup pointless indentation gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 3/4] libcap: enable extended attribute support gustavo.zacarias at free-electrons.com
2016-02-24 14:26 ` [Buildroot] [PATCH v2 4/4] fakeroot: enable capability support gustavo.zacarias at free-electrons.com
2016-02-25 20:50 ` [Buildroot] [PATCH v2 0/4] Add file capability/xattr support Thomas Petazzoni
2016-02-25 21:00 ` Gustavo Zacarias
2016-02-25 21:10 ` Thomas Petazzoni [this message]
2016-02-25 21:29 ` Gustavo Zacarias
2016-02-25 21:34 ` Thomas Petazzoni
2016-02-25 21:26 ` Thomas Petazzoni
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=20160225221004.26bb337b@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--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.