Bug 888360 - packstack is logging to /var/tmp
Summary: packstack is logging to /var/tmp
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 2.0 (Folsom)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: snapshot2
: 2.1
Assignee: Flavio Percoco
QA Contact: Nir Magnezi
URL:
Whiteboard:
Depends On:
Blocks: 911758
TreeView+ depends on / blocked
 
Reported: 2012-12-18 14:53 UTC by Steven Hardy
Modified: 2019-09-10 14:07 UTC (History)
5 users (show)

Fixed In Version: openstack-packstack-2012.2.2-0.6.dev345.el6ost
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 911758 (view as bug list)
Environment:
Last Closed: 2013-02-14 18:23:53 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 20405 0 None None None Never
Red Hat Product Errata RHBA-2013:0260 0 normal SHIPPED_LIVE Red Hat OpenStack 2.0 (Folsom) Preview bug fix and enhancement update 2013-02-14 23:21:02 UTC

Description Steven Hardy 2012-12-18 14:53:14 UTC
Description of problem:

Packstack is logging to /var/tmp, with a path that's obfuscated by a UUID, e.g:

/var/tmp/b09900d1-4282-4ce4-9b7e-9b5ad00f8d23/openstack-setup_2012_12_18_14_40_08.log

Because the logfile location is not output on non-error exit of packstack, it's not necessarily very obvious where to look for the logfiles.

Version-Release number of selected component (if applicable):

openstack-packstack-2012.2.2-0.2.dev211.el6ost.noarch

How reproducible:
Always

Steps to Reproduce:
1. Run a packstack command (e.g packstack --gen-answer-file=foo.txt)
2. Look for logfile output 
  
Actual results:

Get a bit confused as it's not indicated where to look, and it's not under /var/log

Expected results:

Should be logged under /var/log, in an obvious location, so that e.g I find the file above in /var/log/packstack/openstack-setup_2012_12_18_14_40_08.log

Additional info:

Comment 2 Yaniv Kaul 2012-12-18 17:58:59 UTC
I fail to see what's wrong with that - looks like standard practice for installation programs to use /tmp. It also explicitly directs to it at the end of successful or failed installation.

Comment 3 Steven Hardy 2012-12-18 20:59:47 UTC
It doesn't explicitly direct to it unless the command fails, and it doesn't clean up the temporary (and non-obviously named due to the weird uuid directory naming) tree when it silently creates it on success.

Try running "packstack --gen-answer-file=foo.txt"

Also it's logging to /var/tmp/<biguuid>/, which is much less obvious than e.g any of:


/var/log/packstack/openstack-setup_2012_12_18_14_40_08.log
/tmp/openstack-setup_2012_12_18_14_40_08.log
/var/tmp/openstack-setup_2012_12_18_14_40_08.log

If you think it really should stay in /var/tmp then I think the last example above would be OK, provided the man-page mentioned this is where it logs to, it's the silent logging to a non-obvious place which I was pointing out.

Comment 4 Derek Higgins 2012-12-19 11:08:10 UTC
I can output the location of the log file all successes, you right it doesn't output anything if you run
packstack --gen-answer-file=foo.txt
but It does output location on success if it was trying to install something e.g
packstack --answer-file=foo.txt

I have to create a temporary directory to hold puppet templates. And I thought at the time it would be good to keep both in the same location. I also decided not to put them in /var/log because it not a service.

Would simply outputting this location regardless of the result be enough? Or should I move the log file outside of the uuid directory?

btw, when I decided to use a uuid, I was perhaps over thinking the possibility of a malicious user on the system being able to predict puppet manifest file names and having the ability to edit them to install whatever they want on the hosts.

In a separate bug
https://bugzilla.redhat.com/show_bug.cgi?id=887956
I also need to better report errors, I'll be handling that there.

Comment 5 Steven Hardy 2012-12-19 11:37:32 UTC
Hey Derek,

(In reply to comment #4)
> I can output the location of the log file all successes, you right it
> doesn't output anything if you run
> packstack --gen-answer-file=foo.txt
> but It does output location on success if it was trying to install something
> e.g
> packstack --answer-file=foo.txt
> 
> I have to create a temporary directory to hold puppet templates. And I
> thought at the time it would be good to keep both in the same location. I
> also decided not to put them in /var/log because it not a service.
> 
> Would simply outputting this location regardless of the result be enough? Or
> should I move the log file outside of the uuid directory?

So this is just IMHO, but here are my thoughts:

- I think the uuid directory needs to be removed on successful completion, this implies that either we don't maintain a logfile except on error (most CLI utilities don't, instead relying on CLI output which can be tee'd etc?), or that the logfile is somewhere else

- If stuff is going into /var/tmp, it should be in a /var/tmp/packstack directory, otherwise you fill up /var/tmp with obscurely-named directories, which are not ever cleaned up (and aren't removed when you uninstall the openstack-packstack RPM either)

- The FHS[1] doesn't say anything about only services being allowed to log to /var/log, it says "miscellaneous log files", maybe there's some other specification I'm not aware of, but I personally don't see any problem with an application logging to a subdir under /var/log (provided it's documented as doing so, and maybe a switch or config option is provided to disable it).  The advantage of doing it this way is it's the place the vast majority of users expect to find logfiles (IMO/IME)

[1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARLOGLOGFILESANDDIRECTORIES


> btw, when I decided to use a uuid, I was perhaps over thinking the
> possibility of a malicious user on the system being able to predict puppet
> manifest file names and having the ability to edit them to install whatever
> they want on the hosts.

This security-by-obfuscation approach seems wrong to me, we should simply ensure the temporary manifest files have sufficiently strict permissions that they can't be modified.

Comment 6 Flavio Percoco 2013-01-22 17:20:18 UTC
(In reply to comment #5)
> So this is just IMHO, but here are my thoughts:
> 
> - I think the uuid directory needs to be removed on successful completion,
> this implies that either we don't maintain a logfile except on error (most
> CLI utilities don't, instead relying on CLI output which can be tee'd etc?),
> or that the logfile is somewhere else

Looks reasonable.

> 
> - If stuff is going into /var/tmp, it should be in a /var/tmp/packstack
> directory, otherwise you fill up /var/tmp with obscurely-named directories,
> which are not ever cleaned up (and aren't removed when you uninstall the
> openstack-packstack RPM either)
> 

Ditto, /var/tmp/packstack/ sounds good as well.

> - The FHS[1] doesn't say anything about only services being allowed to log
> to /var/log, it says "miscellaneous log files", maybe there's some other
> specification I'm not aware of, but I personally don't see any problem with
> an application logging to a subdir under /var/log (provided it's documented
> as doing so, and maybe a switch or config option is provided to disable it).
> The advantage of doing it this way is it's the place the vast majority of
> users expect to find logfiles (IMO/IME)

Even though it makes sense having log files in /var/log, it also makes sense to have them in the same "working" directory being used since those files should also be removed on succesfuk completion.

Comment 11 Nir Magnezi 2013-01-31 15:59:22 UTC
Verified With: openstack-packstack-2012.2.2-0.8.dev346.el6ost.noarch


packstack now keeps it's logs at the following path:


/var/tmp/packstack/<date>-<time>

For example:

# ls -ltr /var/tmp/packstack/

drwxr-xr-x. 3 root root 4096 Jan 31 11:18 20130131-1118
drwxr-xr-x. 5 root root 4096 Jan 31 11:23 20130131-1120
drwxr-xr-x. 3 root root 4096 Jan 31 15:40 20130130-1744
drwxr-xr-x. 5 root root 4096 Jan 31 15:59 20130131-1558

Comment 15 Kurt Seifried 2013-02-06 05:56:42 UTC
Filed Bz908101 (CVE-2013-0261) to address the security side of this issue.

Comment 16 Alan Pevec 2013-02-07 15:36:51 UTC
Resetting back to VERIFIED for the original issue, verified in comment 11

Comment 19 errata-xmlrpc 2013-02-14 18:23:53 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.

http://rhn.redhat.com/errata/RHBA-2013-0260.html


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