Bug 1168660 - log-collector tar files change "." permissions when extracted
Summary: log-collector tar files change "." permissions when extracted
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-log-collector
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Simone Tiraboschi
QA Contact: Petr Kubica
Depends On:
Blocks: 1171179 1234855
TreeView+ depends on / blocked
Reported: 2014-11-27 14:22 UTC by Petr Kubica
Modified: 2016-03-09 19:59 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, extracting a log collector archive changed the permissions of the directory being extracted into, which caused various other problems within the system. This was caused by the log collector creating its archive in the base folder, archiving also the permission of '.' This was fixed by changing the archive structure by introducing a top-level directory. As a result, archives can be extracted in any location without changing the directory's permissions, as extraction now also creates a top-level directory for files to be extracted under. Additionally, two distinct log collector archives can be extracted in the same directory without overlapping.
Clone Of:
: 1171179 (view as bug list)
Last Closed: 2016-03-09 19:59:25 UTC
oVirt Team: Integration
Target Upstream Version:
stirabos: needinfo-

Attachments (Terms of Use)
rhevm-engine-log (1.32 MB, application/x-gzip)
2014-11-27 14:22 UTC, Petr Kubica
no flags Details
vdsm-log from host with rhel6.6 (630.69 KB, application/x-gzip)
2014-11-27 14:31 UTC, Petr Kubica
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0392 normal SHIPPED_LIVE rhevm-log-collector bug fix and enhancement update 2016-03-10 00:19:00 UTC
oVirt gerrit 35751 master MERGED archive: reorganizing the final tarball archive Never
oVirt gerrit 37900 ovirt-log-collector-3.5 MERGED archive: reorganizing the final tarball archive Never

Description Petr Kubica 2014-11-27 14:22:49 UTC
Created attachment 962065 [details]

Description of problem:
A day ago, I sucesfully added a host to rhevm and everything is OK. Next day I working with backup and restore utility "engine-backup", it seems all is OK. But when I tried add the hosts to rhevm, but it stop at 
"Failed to install Host VHOST. Certificate enrollment failed." 

It's a second time, when it happen to me. Every time I was working on something else. Then I had to reinstall engine. 

I used a different host:

Host added to rhevm a day ago has RHEL-6.6

Version-Release number of selected component (if applicable):
RHEVM 3.5.0-0.22.el6ev

How reproducible:
Not always

Steps to Reproduce:

Actual results:
Cannot add any hosts

Additional info:
attached logs

Comment 1 Petr Kubica 2014-11-27 14:31:01 UTC
Created attachment 962070 [details]
vdsm-log from host with rhel6.6

Comment 2 Alon Bar-Lev 2014-11-28 07:56:42 UTC
Not sure it is related to backup/restore, I did not understand from description if you actually restored or only backed up.

rm: cannot remove `/tmp/ovirt-engine-pki.v2.lock': Permission denied

Please paste output of:

# ls -laLd /tmp/ovirt-engine-pki.v2.lock /etc/pki/ovirt-engine/private
drwxr-x---. 2 ovirt ovirt 4096 Oct 27 22:30 /etc/pki/ovirt-engine/private
drwxr-x---. 2 ovirt ovirt   40 Nov 25 21:28 /tmp/ovirt-engine-pki.v2.lock

if ovirt is not owner of /tmp/ovirt-engine-pki.v2.lock it is probably a leftover from crash.

if ovirt is not owner of /etc/pki/ovirt-engine/private it is probably a restore issue as the permissions are set in packaging (rpm).

Comment 3 Petr Kubica 2014-11-28 09:39:31 UTC
I created a backup of the engine, cleanup the engine and after I restored the engine from backup. http://www.ovirt.org/Ovirt-engine-backup -> but on the same machine. But I don't know, what caused this issue.  

# ls -laLd /tmp/ovirt-engine-pki.v2.lock /etc/pki/ovirt-engine/private
ls: cannot access /tmp/ovirt-engine-pki.v2.lock: No such file or directory
drwxr-x---. 2 ovirt ovirt 4096 Nov 25 18:39 /etc/pki/ovirt-engine/private

when adding the host, ovirt-engine-pki.v2.lock seems to be not created.

Comment 5 Alon Bar-Lev 2014-11-28 10:00:44 UTC
# ls -lad /tmp
drwx------. 5 root root 4096 Nov 28 10:57 /tmp

should be:

# ls -lad /tmp
drwxrwxrwt. 10 root root 61440 Nov 28 03:17 /tmp

so entire system is damaged.

I do not think it is related to backup/restore... reassigning to correct component and closing for now.

if you can reproduce this on clean machine with documented sequence please reopen.

Comment 6 Sandro Bonazzola 2014-11-28 10:11:59 UTC
It would be also nice to understand what changed the /tmp permission, supposing you didn't change them by hand.

Comment 7 Petr Kubica 2014-11-28 11:29:38 UTC
I found what causing this permission on tmp directory:

I created sosreport via rhevm-log-collector
This command created archive in tmp folder sosreport-LogCollector-....tar.xz
Permission was still ok until I runned tar in folder /tmp

#tar -Jxf sosreport-LogCollector-....tar.xz

this change the permission of the /tmp

Comment 8 Sandro Bonazzola 2014-11-28 15:05:37 UTC
So tar is changing "." permission? Moving to log-collector for further investigation.
Simone, can you check if this is due to the way we build the tar file? 

I suggest to reduce the severity to high:
 - it's not likely that a sosreport is opened on the same host producing it
 - manual fix is pretty simple: chmod 777 /tmp (if extracted in /tmp instead of /tmp/whatever

Comment 9 Alon Bar-Lev 2014-11-28 15:11:55 UTC
> So tar is changing "." permission?

always if . is within tarball, you should put leading directory.

> chmod 777 /tmp

chmod 1777 /tmp

or more correctly:

chmod a=rwxt /tmp

Comment 10 Alon Bar-Lev 2014-11-28 15:15:56 UTC
BTW: best was to open a new bug with clear comment#0 and without history.

Comment 11 Sandro Bonazzola 2014-12-02 10:02:32 UTC
Reducing severity since workaround has been provided.

Comment 13 Sandro Bonazzola 2015-02-20 11:07:39 UTC
Automated message: can you please update doctext or set it as not required?

Comment 14 Petr Kubica 2015-04-20 10:23:22 UTC
Verified in 

Comment 17 errata-xmlrpc 2016-03-09 19:59:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.