218726 - Authentification failure with squid and pidentd (LINUX SuSE 7.3)

Status: RESOLVED EXPIRED

(Core :: Networking: HTTP, defect)

Description

[klaus.kuebler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: mozilla-i686-pc-linux-gnu-1.4-sea.tar.gz.bz2

Pidentd scans the file /proc/net/tcp to find the actual LINUX user id.
While using Mozilla there could be found an entry with the correct address pair,
but the user id it always set to 31, the squid user id!
Using other browsers, i can't find an entry with user id 31, but i can find an
entry with the correct address pair and user id!

Reproducible: Always

Steps to Reproduce:
1. selecting manual proxy configuration
2. setup squid with user authentification via pindent
3. try to access a web page with access restictions allowed only to specified user

Actual Results:  
I'll get a error screen from squid with the message "access denied".
The enhanced debug options of pidend shows the results above.

Expected Results:  
Set the propper user id.

Comment 1

[Darin Fisher]

this cannot be a valid bug.  mozilla has nothing to do with squid.  squid is
probably just misconfigured or broken.  you should file a bug against squid.

Comment 2

[klaus.kuebler]

This bug cant't be a squid or identd configuration or bug problem. Please note
that the same configuration is still working with other browsers like Netscape
4.7, Netscape 7.0, KDE2 and KDE3 Konqueror.

Squid will always send a valid authentification request to the identd daemon and
identd scans the local file /proc/net/tcp to find an entry with the requested
local and remote ip-adress/port combinations. You can find the ka_lookup
procedure doing this in the pidentd source file k_linux.c.

If the IP connection is opened by Mozilla then in the file /proc/net/tcp I
always find the entry with wrong user ID = 31. While using other browser, I
always find the an entry with the correct user ID.

As a result of the wrong user id, squid will send a HTML page with the error
message "access denied".  This is the correct behavior of squid under the the
given circumstances.

So I think that it is a special problem with the Mozilla browser during opening
the IP connection. Additionaly Mozilla and Netscape will always swap the own
remote and local IP-address/port pairs in the file /proc/net/tcp. This minor
problem is easy to fix with a dirty hack in the ka_lookup process of pidentd.

Comment 3

[klaus.kuebler]

Attachment: partial pident debug trace

The line 19 is generated by a mozilla internet access via squid. There are two
problems shown:

The local address port C38 is my private proxy port and must be in the
rem_address column.(See in pident procedure ka_lookup in k_linux.c!) You can
see the wrong user id 31!

In line 42 is a propper entry generated by a KDE3 konqueror internet access via
squid. You can see the correct user id 500!

Comment 4

[klaus.kuebler]

Additional information:
I've found the problem with the user agent
   Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Comment 5

[Darin Fisher]

how can this have anything to do with mozilla?  the fact that you only observe
this problem with mozilla does not necessarily mean that mozilla is at fault or
that code in mozilla should change.  

what happens if you run mozilla on a different machine that has no squid userid?
 or have you tried running mozilla from a windows box?

Comment 6

[klaus.kuebler]

I'm normally using mozilla on my private Linux box and there I have the problems.
 
The entry in the file /proc/net/tcp as described above depends from the used
browser. I have used Mozilla and Konqueror simultaneously on the same Linux box
to generate the trace. 
 
There must be a difference between Netscape 7.0, KDE3 Konqueror and Mozilla 1.4
in the way establishing the IP connection to the proxy server. I assume that
there is a bug in the operating system specific code for the adaption to the
Linux operating system. 

I have the same problem with a Mozilla 0.9 release on a different Linux machine
without a own squid process. I don't belive that this is a major detail, but
I'll check this against with the 1.4 release at the weekend.

Comment 7

[klaus.kuebler]

Attachment: IPTABLE generated log file from separate linux box

You can see first the connection from mozilla to squid and than the
authentification request.
Later you find the authentification request, referencing the connection above.
But  identd can't find this connection, I assume that it is closed by mozilla.

I put the identd log into the next attachment!

Comment 8

[klaus.kuebler]

Attachment: IDENTD generated log file

As you can see in the log file the authentification fails. As the result,
mozilla doesn't get the requested web page.

You can find the connection betwenn identd and squid, but no connection between
mozilla and squid. Since the connection between identd and squid comes later
there can't be a timing problem within the trace!

My last dirthy hack doesn't work in this case, because there is no vaild entry
for a mozilla/squid connection in the file /proc/net/tcp

Please note: The Konquerer Browser will work within the same enviroment!

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.