Summary: | net-fs/netatalk authentication failure, but only without debug logging | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Timothy Miller <theosib> |
Component: | Current packages | Assignee: | Network Filesystems <net-fs> |
Status: | RESOLVED OBSOLETE | ||
Severity: | major | CC: | flameeyes |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://sourceforge.net/tracker/index.php?func=detail&aid=3159355&group_id=8642&atid=108642 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Timothy Miller
2011-01-16 18:26:36 UTC
Notes: Leaving debug logging on is not an acceptable work-around, because it floods my /var/log/messages with messages, rapidly using up disk space and drowning out other messages. This is a link to the netatalk bug I filed on sourceforge: https://sourceforge.net/tracker/index.php?func=detail&aid=3159355&group_id=8642&atid=108642# could be a timing bug ... the debug logging could just be slowing things down just like changing the optimization Yeah. Another thing that fixes the problem is leaving on PAM debug messages. Due to a bug in openrc (not logging stdout/stderr of daemons), the messages go nowhere, but nevertheless, authentication doesn't fail. So... why would changing timing cause auth to pass or fail? I've found out a few other things. One is that there are others having this problem. For instance: http://ubuntuforums.org/showthread.php?p=10607522#post10607522 The other is that people using Kerberos only just don't seem to have this trouble. So, either PAM itself has a bug that we're exposing, or Netatalk has a PAM-related bug. This kinda narrows it down a bit, at least. My suspicion is that Netatalk was never tested with the version of PAM that Gentoo has in ~amd64, so there's an incompatibility. Is this with DHX1 or DHX2? I'm not actually sure how to determine that. Can you give me a hint? Also, I've since upgraded to the latest netatalk, but I haven't actually tested it yet. I've been using alternative solutions that don't have the authentication problem. Though the OP didn't mention what version of OSX is being used on the client side I think this bug is related to Apple having disabled the use of DHX (version 1) in OS X 10.7 (Lion). Netatalks' default -uamlist is 'uams_dhx.so,uams_dhx2.so' and I think whats happening is DHX (version 1) is tried but one side or other isn't waiting for the next authentication method. This might explain why LOG_DEBUG has the effect it does, it creates enough of a delay for the second authentication method to be negociated. Given that Apple has disabled DHX1 is might be a good idea to reverse the order of the -uamlist, with uams_dhx2.so being the first in the list. A recent post in the forums re net-fs/netatalk-2.2.3 seems to suggest that regardless of both DHX and DHX2 being listed in -uamlist if DHX fails, DHX2 is not tried, and authentication fails. It seems to me this is related to the report given in this bug. The post can be found here: http://forums.gentoo.org/viewtopic-p-7061882.html It'd be good to see this bug CLOSED, but as I'm no longer maintaing any netatalk servers, nor have any local (OSX) clients I could test with, I'm not able to provide more help than this, sorry. best regards ... khayyam I was having this problem with Snow Leopard. I never tried it with Lion. |