Date: Wed, 9 Mar 2016 10:17:15 -0500 From: Vincent Batts <vbatts@hashbangbash.com> To: freebsd-hackers@freebsd.org Subject: Fwd: [RFE] mtree support for extattr? Message-ID: <CAN6Zp5zfQd47n4xZ66wfKWJvnL_-eVrB=r9MMgY2_7VuiCN0oA@mail.gmail.com> In-Reply-To: <CAN6Zp5zej%2BEZi7U3L2AXR9CLbBhJsNBiG9SbP55vmqAhTPO_gQ@mail.gmail.com> References: <CAN6Zp5zej%2BEZi7U3L2AXR9CLbBhJsNBiG9SbP55vmqAhTPO_gQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello all,
This is a first post from me. The `mtree` utility (./contrib/mtree/)
and the specs that it produces and validates has found it's way into
projects that I am involved in. While the projects are initially very
Linux focused, they are not limited to such. There is an mtree-port
that has been started for Linux, but is not widely packaged yet. Also,
libarchive has support for parsing and creating mtree specs.
On most Linux filesystems, extend attributes are used commonly for
storing ACLs, capabilities, etc. These attributes are something that
most definitely would be interesting keywords to include in the spec
of a directory hierarchy.
>From my researching, it seems that extattr support for mtree on
freebsd is not present, while the sys/extattr.h and UFS could support
it.
It seems this is a valuable feature to add and would be widely useful.
Some of the mechanics would be interesting to handle the collation of
the extattr data into the keywords for files in the mtree spec. As the
key/values are namespaced, perhaps the mtree keyword would use the
namespace.key and prefix it with 'extattr.' or 'xattr' or similar.
Such that the entry in the mtree spec looks like
```
my.file \
mode=0644 size=24542 time=1455996582.000000000 \
extattr.system.mykey=myvalue \
sha512digest=f758e6d04b527cc024aa70ffaaa75b4899429498d246f41a057753dc51b7d49e0f6b512c1f1920435585067209863c529b2038101ce0576138c7eee7ca359b7c
```
Some issues that I have with this is the information leak of the
values of the extended attributes. Also, on Linux xattrs are expected
to be ascii strings, it is not uncommon to find binary content in the
value.
For these two cases, it seems nicer to just include a checksum of the
value of each extended attribute. This then requires an election to
which hash to use for the checksum digest.
I look forward to your response and next steps!
vb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6Zp5zfQd47n4xZ66wfKWJvnL_-eVrB=r9MMgY2_7VuiCN0oA>