Bug 717684

Summary: support for acl, xattr, and selinux completely broken
Product: [Fedora] Fedora Reporter: Trever Adams <trever>
Component: tarAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 15CC: basile, dmitry, kdudka, mishu, ovasik
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tar-1.26-2.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-02 19:07:30 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Anthony's patch extended for ACLs and SELinux
none
[PATCH 2/2] misc: partially revert upstream commit 4bde4f3 none

Description Trever Adams 2011-06-29 11:02:43 EDT
Description of problem:
All of my systems have all user file systems (anything you would want to back up) mounted with user_acl and xattr. These are all ext3 or ext4 file systems (the only ext3 ones left are /boot on some machines).

When doing an amandabackup using tar with the xattr and user_acl options to backup sent to tar, I get a lot of this:

  ? /bin/tar: ./ConsoleKit: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./ConsoleKit/run-seat.d: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./ConsoleKit/run-session.d: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./ConsoleKit/seats.d: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./NetworkManager: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./NetworkManager/dispatcher.d: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./X11: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./X11/applnk: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./X11/fontpath.d: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./alternatives: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./amanda: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./amanda/DailySet1: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./audisp: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./audisp/plugins.d: Warning: Cannot acl_get_file: No such file or directory
  ? /bin/tar: ./audit: Warning: Cannot acl_get_file: No such file or directory

It only shows on directories. I have never seen it on a plain file.

I do not know if this is a kernel bug or a tar bug. However, to have warnings like this when nothing is really wrong is quite a problem as it grows the AMANDA report and causes it to say STRANGE instead of SUCCESS.

Version-Release number of selected component (if applicable):
tar-1.25-6.fc15.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Setup a system to mount everything with user_acl and xattr 
2. do a tar with options --acls --selinux --xattrs on /etc 
3. Watch the warnings spew out
  

Additional info:
This also affects the latest I tried with F14 (about a month or two ago).
Comment 1 Ondrej Vasik 2011-06-29 11:19:27 EDT
Strange, it works just fine on my machine with locally compiled f15 tar, maybe some issue in libacl - could you please try to get ltrace of run for the one failing directory? Are these directories (where acl_get_file complains about not existing file or directory) on the disk? Could you please write the whole tar command you are using for the backup? Maybe there is some issue with some cwd change... similar to issue https://bugzilla.redhat.com/show_bug.cgi?id=688567 ...
Comment 2 Trever Adams 2011-06-29 11:34:50 EDT
I will try to do this later today or tomorrow. As a note, the files are in the tarball, it just seems to be complaining about the xattr, user_acl stuff. Actually, I forgot that when I tested this with tar directly it worked if I was in the right directory. It didn't work if I emulated the tar that Amanda does.

/bin/tar --create --file /dev/null --directory / --one-file-system --atime -preserve=system --acls --selinux --xattrs --listed-incremental /var/lib/amanda/gnutar-lists/HOST_FQDN__0.new --sparse --ignore-failed-read --totals --exclude-from/var/log/amanda/amgtar._.20110629092945.exclude.

I hope I got the spaces right on this as this is from /proc/pid/cmdline

The excludes knock out /etc, /home and /var for the ones for etc I think the only change is the --directory and the excludes. Yes, that is the only difference. The excludes just go completely away in /home and /etc as there is nothing to exclude in my setup.

Doing an ltrace on this will be a bit difficult as I do not remember how I duplicated it with tar directly.
Comment 3 Kamil Dudka 2011-06-30 06:45:16 EDT
(In reply to comment #2)
> Doing an ltrace on this will be a bit difficult as I do not remember how I
> duplicated it with tar directly.

If the tar process runs for a long enough period and still produces the warnings, you can find the process on your system manually and attach ltrace to the corresponding PID using the -p option of ltrace.
Comment 4 Dmitry S. Makovey 2011-07-11 03:24:49 EDT
Looks like the same issue here (but mine slobbers files too):

tar: ./lib/python2.7/site-packages/cherrypy/scaffold/__init__.py: Cannot setfilecon: No such file or directory

I'm trying to migrate /usr from one FS to another, with:

# tar --selinux --xattr -cf - -C /usr . | tar --selinux --xattr -xpf - -C /mnt/tmp

Above was the result of that action... I have also noticed that SELinux attributes were not set on created directories (not sure whether they were supposed to be created only after files themselves were all created...)


gamer ~ # ls -lZ /usr/
...
dr-xr-xr-x. root root system_u:object_r:lib_t:s0       lib
drwxr-xr-x. root root system_u:object_r:usr_t:s0       local
...
gamer ~ # ls -lZ /mnt/tmp
dr-x------. root root unconfined_u:object_r:file_t:s0  lib
drwxr-xr-x. root root unconfined_u:object_r:file_t:s0  local

I interupted process before it had a chance to "finish"
Comment 5 Dmitry S. Makovey 2011-07-11 03:26:46 EDT
if it was unclear from my previous comment - I posted only a single message - there are thousands of those flying by on the screen when I execute the original command.
Comment 6 Anthony G. Basile 2011-09-24 12:52:10 EDT
I think I've found the problem and I have a fix.  For details see the following gentoo bug:

   https://bugs.gentoo.org/show_bug.cgi?id=382067

look at comments #6 (steps for hitting the issue) and #7 (code analysis and fix).

Basically, the current patch doesn't save acls or xattrs, just selinux labels, and only by luck.  In brief what's happening is that, when dump_file0() in create.c makes the following call:

     xattrs_xattrs_get(st, p, fd);

its calling with fd=0 in cases of files.  But in xattr_xattrs_get there is a check:

              (fd == -1) ?
              ((xret = llistxattr (file_name, xatrs, xsz)) == -1) :
              ((xret = flistxattr (fd, xatrs, xsz)) == -1)

So, it expects to list xattrs by file_name if fd = -1 or by file descriptor if fd != 1.  But calling flistxattr() with fd=0 is wrong.  The reason this happens is because fd is set to zero at the top of dump_file0() and only gets reset to a real file descriptor if subfile_open() is called.  So fd == 0 means "I have no file desriptor" in dump_file0(), whereas fd == -1 means the same in xattrs_xattrs_get().

The fix is to replace the one and only call xattrs_xattrs_get(st, p, fd); in create.c to

    if (fd == 0)
      xattrs_xattrs_get(st, p, -1);
    else
      xattrs_xattrs_get(st, p, fd);

This is a pretty trivial fix, do you need a patch?
Comment 7 Anthony G. Basile 2011-09-24 13:01:13 EDT
Grr ... sorry a minor error but I don't want to cause confusion.  Please change the line ...

it expects to list xattrs by file_name if fd = -1 or by file descriptor if
fd != 1.

to

it expects to list xattrs by file_name if fd = -1 or by file descriptor if
fd != -1.

That last number should be -1.
Comment 8 Kamil Dudka 2011-09-24 13:20:27 EDT
Anthony, thank you for the reproducer and the patch!  This is actually a regression caused by update of tar to the new upstream release.  The version of tar we have in F-14 seems to work fine using the scenario above.
Comment 9 Kamil Dudka 2011-09-26 10:13:11 EDT
Created attachment 524913 [details]
Anthony's patch extended for ACLs and SELinux

This seems to fix the creation with fd == 0.  Unfortunately, the extraction is still broken in case -C is used.  This is caused by the following upstream commit, which the xattr patch was not ready for:

http://git.savannah.gnu.org/gitweb/?p=tar.git;a=commitdiff;h=4bde4f3
Comment 10 Kamil Dudka 2011-09-26 10:18:31 EDT
Created attachment 524917 [details]
[PATCH 2/2] misc: partially revert upstream commit 4bde4f3

As a hotfix I will partially revert the upstream commit 4bde4f3.  A proper solution would require to wrap all those name-based calls by the open-at.c wrapper.  Note that selinux-at already exists as a module in gnulib, although tar does not include it yet.  I am not sure about the acl/xattr functions...
Comment 11 Kamil Dudka 2011-09-26 10:47:31 EDT
fixed in tar-1.26-2.fc17
Comment 12 Fedora Update System 2011-09-26 10:57:59 EDT
tar-1.26-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/tar-1.26-2.fc15
Comment 13 Fedora Update System 2011-09-26 10:58:08 EDT
tar-1.26-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/tar-1.26-2.fc16
Comment 14 Fedora Update System 2011-09-26 12:48:11 EDT
Package tar-1.26-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tar-1.26-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/tar-1.26-2.fc16
then log in and leave karma (feedback).
Comment 15 Trever Adams 2011-09-27 03:58:20 EDT
I have not yet verified that this tar is backing up xattr and user_acls. However, it does get reed of the weirdness when called from AMANDA. I will try to do a back/restore of a test file and verify that user_acls and xattrs are working.
Comment 16 Kamil Dudka 2011-09-27 04:34:01 EDT
Great, thanks for testing!  Please let us know if there was any badness going on.
Comment 17 Fedora Update System 2011-10-02 19:07:23 EDT
tar-1.26-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2011-10-03 14:07:42 EDT
tar-1.26-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.