After discussing this with upstream it became clear that the documentation is incorrect and it is deliberate that only the "user.*" extended attributes are applied by default during extraction.
"This decision was done because only user.* attributes are 100% safe to extract. The security.* (especially capabilities) can have some binary format specific to the box creating the archive but incompatible with host extracting the archive." https://lists.gnu.org/archive/html/bug-tar/2019-06/msg00001.html The man for tar should be updated to reflect that to avoid any confusion. ** Summary changed: - only user.* extended attributes restored upon extraction + its undocumented that only user.* extended attributes restored upon extraction ** Summary changed: - its undocumented that only user.* extended attributes restored upon extraction + its undocumented that only user.* extended attributes are restored upon extraction -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1831150 Title: its undocumented that only user.* extended attributes are restored upon extraction Status in GNU tar: Unknown Status in tar package in Ubuntu: New Status in tar package in Debian: New Bug description: The tar info page and upstream documentation indicate that when --xattr is used "all names are stored in the archive (or extracted, if using '--extract')", however when using --xattr with extract the security.capability extended attributes are not restored. If one also uses "--xattrs-include=*" then the security.capability extended attributes will be restored. [Test Case] mkdir orig restore touch orig/file_with_capability_and_user_xattr setcap cap_net_raw=p orig/file_with_capability_and_user_xattr (eoan-amd64)root@impulse:/tmp# getfattr -m . -d orig/file_with_capability_and_user_xattr # file: orig/file_with_capability_and_user_xattr security.capability=0sAAAAAgAgAAAAAAAAAAAAAAAAAAA= user.testkey="testvalue" (eoan-amd64)root@impulse:/tmp# tar c --xattrs --acls --directory orig/ . | tar x --xattrs --acls --directory restore/ (eoan-amd64)root@impulse:/tmp# getfattr -m . -d restore/file_with_capability_and_user_xattr # file: restore/file_with_capability_and_user_xattr user.testkey="testvalue" (eoan-amd64)root@impulse:/tmp# tar c --xattrs --directory orig/ . | tar x --xattrs --xattrs-include=* --directory restore/ (eoan-amd64)root@impulse:/tmp# getfattr -m . -d restore/file_with_capability_and_user_xattr # file: restore/file_with_capability_and_user_xattr security.capability=0sAAAAAgAgAAAAAAAAAAAAAAAAAAA= user.testkey="testvalue" I think tar's extract behavior should be changed to match that of create so that all names are actually extracted. To manage notifications about this bug go to: https://bugs.launchpad.net/tar/+bug/1831150/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
