[fetchmail-devel] [Bug #18794] BUG in libdispatch client - OSX ML 10.8.2

[<ad...@be...>]

Bug #18794, was updated on 2012-Nov-14 01:12
Here is a current snapshot of the bug.

Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: madman1234
Assigned to : m-a
Summary: BUG in libdispatch client - OSX ML 10.8.2

Details: I installed fetchmail using mac ports. But everytime I start fetchmail (SSL included), I receive the following message in /var/log/mail.log

[...]
BUG in libdispatch client: Do not close random Unix descriptors
[...]

I have compiled the latest fetchmail version by myself, but I receive the same message. 

Fetchmail itself works, but what does it means? 

If I should ran any debugs, just let me know :)

Thanks
Soeren

Follow-Ups:

Date: 2012-Nov-19 01:58
By: madman1234

Comment:
1. What is libdispatch?
Libdispatch is part of the OS. It's linked into virtually every program,
as you can see from:
 {{{
 otool -L /usr/lib/libc.dylib
 }}}

2. Why is fetchmail on macports linking to it?
It is done by default from OSX. Macports is here not involved.

3. Why does libdispatch require an application to keep random file descriptors open?
I don't know.

4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream?
It is not macports specific, it seems to be a standard behavior by default (OSX)

Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment.
The error message appears only once, after fetchmail tries to fetch mail via POP3 SSL. If there is no POP3 Server configured, then there is no error message on startup.

Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it.
I have compiled fetchmail by myself, wihtout macports, and the same issue occurs. 

Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck.
I don't want to use getmail. Fetchmail is verfy stable and I like it a lot.

5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem.
With -d 0 there is no error message. 


I am running fetchmail now on my OSX 10.8.2 Server. The error message appears when fetchmail starts, the program itself runs for 2 days now. All E-Mails are delivered correctly.
-------------------------------------------------------

Date: 2012-Nov-14 22:08
By: m-a

Comment:
Some questions and notes:

1. What is libdispatch?

2. Why is fetchmail on macports linking to it?

3. Why does libdispatch require an application to keep random file descriptors open?

4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream?

Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment.

Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it.

Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck.

5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem.

Please report back with answers to these four questions, and possibly with macports statements to the notes.
-------------------------------------------------------

Date: 2012-Nov-14 01:27
By: madman1234

Comment:
Here is the answer from macports:

[...]
http://trac.macports.org/ticket/36984#comment:3

This message is printed by libdispatch (and is thus Apple-specific). Apparently fetchmail closes file descriptors that are used by libdispatch, which terminates the process using this message when this happens. I guess one would have to attach a debugger, see where the file descriptor is closed and see whether this actually is a "random" file descriptor and what can be done about it. The maintainer might also consider forwarding this to upstream fetchmail. 
[...]

Do you have such a debug script? 

Thanks

-------------------------------------------------------

For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18794&group_id=1824