194770 - Multiuser SideCar (Kerberos-related) not functional with Mozilla 1.3

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[Fred Trinkoff]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:13b) Gecko/20030212

Multiuser SideCar is a program that works with Kerberos for non-Kerberized
applications. In order to distinquish between multiple users, it uses outgoing
port numbers. Mozilla 1.3b seem to do something different with ports so that the
SideCar request cannot distinquish which user's credentials are being requested.
Here is the error in the log:

02/21/03 08:14:45 132.236.218.30:59554 getKAT [e-mail] 
* 1039904 can't find client associated with uid, 1039904.

According to the main developer of Cornell's Mac OS X SideCar, the problem can
be summarized as "Looks like when v 1.3b of mozilla makes the server connection
it either uses a port that is assigned to another user or a port that isn't in
use anymore when the sidecar request comes in." Testing out the classic (OS 9)
SideCar works fine, because that is not a multiuser version of SideCar and
therefore doesn't need to worry about port numbers.

Most evidence says 1.3a worked fine, including redownloading the old version. I
thought it didn't work in either, but I am not now sure which version I was
using a couple weeks ago when I first noticed the problem.

I realize this might be hard for you to solve, not having access to Cornell's OS
X SideCar, so I am providing you with the information of the developer. Her name
is Joy Veronneau and her email is [e-mail] .

Reproducible: Always

Steps to Reproduce:
1. Open OS X SideCar
2. Go to a SideCar protected web page
3. There's no step 3 :-)

Actual Results:  
Got a "SideCar Required" page.

Expected Results:  
Should have been prompted for my Kerberos name and password.

Comment 1

[Greg K.]

Fred, Mozilla's developers aren't likely to contact SideCar's developer by
e-mail. If you like, you may invite her to contribute to this bug, though.

Is this "SideCar" something you can provide a link to?

Comment 2

[Joy Veronneau]

Here is the basic idea behind how sidecar works.A department here at cornell can set up a webserver which requires kerberos authentication to view a page.  They run special authentication software to do this.A user on Mac OS X that wants to view a protected page first starts up the sidecar program on their mac.  This program listens for special messages on port 913.  Then the user will type in the address of the web page they want to get to using any browser.If the page is protected, the web server says "Oh, I need authentication for this page" and sends a special message to the client's sidecar program on port 913.  Encoded in this message is the OUTGOING PORT number that the webserver received the request from.  Sidecar looks through mac os x process table to see which user is associated with that port.  So, on a multiuser system, multiple users can each be authenticated individually based on this port number.With 1.3b of Mozilla, this outgoing port number is invalid by the time sidecar gets the message, so it can not authenticate based on port number.Hope this helps explain the problem.Joy

Comment 3

[Fred Trinkoff]

As for getting your hands on SideCar, I could send you the link, but you need to
authenticate with a web form to download it off campus (or with SideCar itself
if you're just upgrading/reinstalling), so it won't do you any good. You could
certainly ask Joy ([e-mail], that is) if we're able to provide you with
a copy, I'm not 100% sure of the policy of that. I'm sure we can't provide you
with a username / password, but it might be okay to have the software to install
it and at least watch how it works, and see if it prompts you with an
unconfigured Kerb dialog. Again, Joy'll need to figure out the policy on that.

Comment 4

[Joy Veronneau]

Ok, I was just reading through Fred's comments.  I don't think it is necessary for you to have the SideCar program in order to solve this bug.  You should be able to look at code differences and network statistics between versions 1.3a and 1.3b and figure out why/how the connection port numbers are behaving differently.Thanks,Joy

Comment 5

[Fred Trinkoff]

I just wanted to report that the bug still exists in the final 1.3 release. Have
you had any luck. I've been a long time Mozilla user, but if this continues I'll
be forced to pick something else.

Comment 6

[Matthias Versen [:Matti]]

marking NEW
looks like a regression from the async IO landing

Comment 7

[Doug Turner (:dougt)]

.

Comment 8

[Joy Veronneau]

Hi,I have new information on this.  A user at dartmouth wrote me the following:-----------It appears to me that the port number is getting passed to the web server & cgi correctly.The problem may be that Mozilla is using IPv6.If I do an "lsof" of Explorer while it's talking to the web server I see:LaunchCFM 7955 davidg   24u  inet 0x01c4b50c      0t0      TCP rocky.kiewit.dartmouth.edu:52045->lemitar.dartmouth.edu:http (ESTABLISHED)Mozilla looks like:mozilla-b 7952 davidg   27u  sock                 0t0          no further information on AF_INET6i.e., lsof doesn't know how to interpret the IPv6 address. Maybe casd can't do it either?-------casd that is mentioned in the above quote is a daemon that is part of the SideCar program.  It uses some lsof code to look up the outgoing port number and match it back to a userid.I am wondering if one of you developers would be willing to open up a conversation with me so that we could possibly get this fixed in SideCar if possible.  It is now affecting users at both Cornell and Dartmouth.I have questions like "what changed between 1.3a and 1.3b that might cause this problem?" I find it hard to believe that you would make a change as big as going to IPv6 between 1.3a and 1.3b so I suspect that may not be the problem?[e-mail]

Comment 9

[Fred Trinkoff]

Would you guys please communicate with our developers on what changed that might
be causing this to happen. It's been nearly two months since we heard anything
from you. I've been less than impressed with the your responsiveness lately.

-Fred

Comment 10

[Darin Fisher]

fred:

my appologies, but please understand that we are quite swamped with a large
number of bugs.  if anyone can help debug this problem it would be most
appreciated.  i have futured this bug because i know that i will not have time
to work on this bug anytime soon (Target Milestone = Future).

one thing you could do to help is to try the most recent nightly build of
mozilla that you can get your hands on.  please see

  http://ftp.mozilla.org/pub/mozilla/nightly/latest

it would be helpful to know whether or not the latest nightly build has this bug.

thanks!

Comment 11

[Joy Veronneau]

Hi,
I don't really think this is a BUG in Mozilla.  Rather, something has changed
in Mozilla between 1.3a and 1.3b that afffects how my program works.

When Mozilla opens a port and contacts a server on our campus, the server will send 
that
client's outgoing port number BACK to the client in the authentication request.

My program then uses lsof to link 'the port the request went out on' to a UID on the client 
machine.

The problem is that Mozilla seems to now be using IPv6 and the latest lsof I can get for
MacOSX doesn't support that yet... at least that is my theory.

Can someone just tell me please if Mozilla has recently begun to use IPv6.   Or, any other
ideas about what changed between Mozilla versions 1.3a and 1.3b.

I just tried 1.3.1 and the behavior is the same.

Thank you!
[e-mail]

Comment 12

[Nikolay Shopik]

Is this still issue when using latest version?

Comment 13

[Joy Veronneau]

Well, it doesn't matter any more. we have retired sidecar. Thanks.

Joy