Description of problem: Copying files using "bacula" (Backup tool)"cpio", "rsync" or "tar" drops file capabilities. It appears these tools do not even provide any options to deal with such attributes. So far, only "cp --preserve=all" appears to be usable to copy files including their capabilities. Implications: How do you backup your system? Are you sure you can really restore a fully working root file system??? Background story: After updating a number of systems from Fedora 15 to Fedora 16, "rlogin" stopped working for regular users: $ /usr/bin/rlogin ts0 rcmd: socket: Permission denied On some of the updated systems it continued to work, though. Investigation showed that somehow the required capabilities had been lost during the update. On the working systems I see: $ getcap -v /usr/bin/rlogin /usr/bin/rlogin = cap_net_bind_service+ep while on the broken systems I get $ getcap -v /usr/bin/rlogin /usr/bin/rlogin This gets confirmed by package verification: -> rpm -q --verify rsh-0.17-65.fc15.x86_64 ........P /usr/bin/rcp ........P /usr/bin/rlogin ........P /usr/bin/rsh Updates were done using yum, following the instructions at http://fedoraproject.org/wiki/YumUpgradeFaq Some magic in the update procedure must have lost the capabilities. During the update, I usually copy the content of the root file system to a new file system in another logical volume. I keep the old volume as backup and for fallback if needed. Usually I use cpio or tar to perform the copy. Version-Release number of selected component (if applicable): bacula-*-5.0.3-13.fc16.i686 cpio-2.11-4.fc16.x86_64 rsync-3.0.8-2.fc16.x86_64 tar-1.26-2.fc16.x86_64 How reproducible: 100% Steps to Reproduce: 1. Select some files that have capabilities set: # cd /usr/bin # getcap -v rcp rlogin rsh rcp = cap_net_bind_service+ep rlogin = cap_net_bind_service+ep rsh = cap_net_bind_service+ep 2. Copy files to some other place: 1) Using cpio: # rm -fr /tmp/foo # mkdir /tmp/foo # ls rcp rlogin rsh | cpio -vBpdum /tmp/foo /tmp/foo/rcp /tmp/foo/rlogin /tmp/foo/rsh 10 blocks 2) Using tar: # rm -fr /tmp/foo # mkdir /tmp/foo # tar cf - rcp rlogin rsh | ( cd /tmp/foo ; tar xpvf - ) rcp rlogin rsh 3) Using rsync: # rm -fr /tmp/foo # mkdir /tmp/foo # rsync -av --delete rcp rlogin rsh /tmp/foo/ sending incremental file list rcp rlogin rsh sent 47816 bytes received 69 bytes 95770.00 bytes/sec total size is 47640 speedup is 0.99 4) Using bacula: - Try and restore /usr/bin/rsh from your latest backup 3. Check capabilities on the copies. In all cases we get: # getcap -v /tmp/foo/* /tmp/foo/rcp /tmp/foo/rlogin /tmp/foo/rsh I. e., the (needed for correct function) capabilities are lost. Actual results: Copies have their capabilities lost. Expected results: There should be a way that all tools that deal with archiving, restoring and copying of files not only include the easily visible ownership and file permission information, but also the more delicate and less visible features like capabilities. file permissions Additional info: Not sure how to correctly report this. It affects a number of tools, and has serious impact on many systems. I guess the number of people who are still able to correctly restore a system from their backups is much lower than many would expect :-(
Update: - rsync: Using the "-X" option (preserve extended attributes) will copy capabilities as well. - bacula: Is actually supposed to be able to save and restore this when using "aclsupport = yes" and "xattrsupport = yes" in the FileSet definition. In my tests this did not work, though. A configuration issue under F16 ?
Can you please file bugs against the individual components? You can mark them as 'blocking' this bug in bugzilla, so that this bug can be used for tracking.
Bacula rawhide 5.2.4 fixes the problem about file capabilities; they can be backed up and restore correctly.
I think it may be possible to discover the various file capabilities from the rpm database. For example, this seems like it may work: sh-4.2$ rpm --qf "[%{FILECAPS} %{FILENAMES}\n]" -qa | grep '^=' = cap_dac_override,cap_fowner,cap_setuid,cap_setpcap,cap_sys_admin,cap_sys_nice+ep /usr/sbin/seunshare = cap_net_raw+ep /usr/sbin/mtr = cap_net_raw+ep /bin/ping = cap_net_raw+ep /bin/ping6 = cap_dac_override,cap_setgid,cap_setuid+ep /usr/sbin/suexec = cap_ipc_lock+ep /usr/bin/gnome-keyring-daemon = cap_net_bind_service+ep /usr/bin/rcp = cap_net_bind_service+ep /usr/bin/rlogin = cap_net_bind_service+ep /usr/bin/rsh = cap_chown,cap_fowner+ep /usr/libexec/pt_chown = cap_net_raw+ep /usr/sbin/fping = cap_net_raw+ep /usr/sbin/fping6 = cap_net_admin,cap_net_raw+eip /usr/sbin/dumpcap One could perhaps use this information to fix the file capabilities after restoring data from a backup. This is obviously not an ideal long-term solution, but it may be a simple hack to get by until the various tools are patched. Please let me know if I am mistaken about this. Regards, Andy
Created attachment 584681 [details] Shell script to fix file capabilities based on rpm database info after restoring files In case it's helpful for others, this shell script queries the rpm database for information about files where file capabilities have been set, and it reconciles this versus the actual files in the filesystem. With the -v flag, it simply reports differences. Without -v, it attempts to fix the file capabilities. This can be used to fix file capabilities after doing a restore from a tar backup, etc.
Hi Andy, The script is very useful. Maybe it will be a good idea to have it added as an option to rpm as the --setperms and --setugids. Cheers, Cristi
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.