[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#684735: unblock: ganglia (security)




On 14/08/12 19:03, Adam D. Barratt wrote:
> On Mon, 2012-08-13 at 14:11 +0000, Daniel Pocock wrote:
>>> Please could we have a full source debdiff for a proposed upload as part
>>> of this bug log?  It makes it far clearer what was requested to be acked
>>> and what was (or wasn't) acked.
>>
>> debdiff attached
> 
> Thanks.  A few queries:
> 
> +Uploaders: Daniel Pocock <daniel@pocock.com.au>
> [...]
> +DM-Upload-Allowed: yes
> 
> Those aren't mentioned at all in the changelog, as far as I can tell.
> Were they acked by the maintainer?
> 

See separate email from Stu (also confirmed in an email on the security bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683584 )

> +Vcs-Git: git://git.debian.org/collab-maint/ganglia.git
> +Vcs-Browser: http://git.debian.org/?p=collab-maint/ganglia.git;a=summary
> 
> Those should also be mentioned in the changelog.
> 

done

> diff -Nru ganglia-3.3.5/debian/patches/debian-changes-3.3.8-1 ganglia-3.3.8/debian/patches/debian-changes-3.3.8-1
> [...]
> +--- ganglia-3.3.8.orig/gmond/modules/python/README
> ++++ ganglia-3.3.8/gmond/modules/python/README
> +@@ -101,11 +101,11 @@ follows:
> +     module {
> +       name = "python_module"
> +       path = "modpython.so"
> +-      params = "/usr/local/lib64/ganglia/python_modules"
> ++      params = "/usr/lib/ganglia/python_modules"
> +     }
> +   }
> + 
> +-  include ('/usr/local/etc/conf.d/*.pyconf')
> ++  include ('/etc/ganglia/conf.d/*.pyconf')
> + 
> 
> Were these intended to be included?  Is there a reason they're not a) a
> separate patch and b) in the changelog?
> 

This is a side-effect of NOT running the bootstrap from debian/rules

README is generated from the README.in file

Consequently, the README file is now the real upstream version, and it
shows actual paths on Debian


> diff -Nru ganglia-3.3.5/debian/rules ganglia-3.3.8/debian/rules
> --- 
> [...]
>  	# Add here commands to configure the package.
> -	./bootstrap
> -	chmod +x configure libmetrics/configure
> +	#./bootstrap
> +	#chmod +x configure libmetrics/configure
> 
> Why does "bootstrap" go away?  I spotted that the script is also
> removed.

This has some history to it upstream.

upstream migrated SVN -> git and made various autotools changes, and
then added a whole lot of new stuff without correctly putting everything
under the control of autotools `make dist'

Wearing my upstream release manager hat, I went over it a little bit too
aggressively and added many missing things to `make dist' so that the
release tarballs were complete.

Then we discovered people running the bootstrap script when they
shouldn't be - and getting all kinds of problems.  It is ONLY meant to
be run by the upstream developers when working directly from the code in
upstream git VCS.

Consequently, the bootstrap script is NOT in the upstream tarball 3.3.8,
and should not be called from debian/rules

The bootstrap script basically calls things like autoreconf from the
autotools suite.


> +int
> +get_apr_os_socket(apr_socket_t *socket)
> +{
> +  return socket->socketdes;
> +}
> 
> Was there a problem with the direct uses of "sock->socketdes" which were
> previously used?

That's my handiwork too (as upstream developer)

This is an evil hack, accessing a private member of the struct
apr_socket_t.  Notice that one of the source file includes a local copy
of the full struct declaration, copied from a private part of the apr
sources.

Nonetheless, it is a hack that has been used in multiple places in the
ganglia code base for a long time.

To make it more obvious that it is a hack, I have created this function
to encapsulate the hack - it is the same code that was repeated in other
places in ganglia, now instead of each module accessing
socket->socketdes directly, they all access it through this function.
In a future version, the function can be deprecated to give warnings
about the hack.

> Out of interest, do you know wish parts of the diff address this
> changelog entry?
> 
> +  * Fix issue where Ganglia fails to start with NetworkManager
> 
Yes, I coded that to make sure it `just works' on Debian workstatations

It is this commit:
https://github.com/ganglia/monitor-core/commit/c84644a95d6354009568c8fe769656ebad2313cf

I've updated the changelog to refer to the bug:

  * Fix issue where Ganglia fails to start with NetworkManager
    (Closes: #638628)

Thanks for taking the time to look over Ganglia

Regards,

Daniel


Reply to: