Bug 589788 - Can't seem to authorize to GSSAPI due to error in base64 decoding
Can't seem to authorize to GSSAPI due to error in base64 decoding
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sendmail (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Jaroslav Škarvada
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-06 17:19 EDT by melson
Modified: 2013-03-06 07:59 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-06 07:59:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
simple maxinpline patch (1.28 KB, patch)
2010-05-09 19:04 EDT, melson
no flags Details | Diff
maxinpline patch w/ auth sanity check included (3.02 KB, patch)
2010-05-09 19:07 EDT, melson
no flags Details | Diff

  None (edit)
Description melson 2010-05-06 17:19:46 EDT
Description of problem:

Attempting to authorize via GSSAPI on various clients (alpine, thunderbird) isn't working.  The error logs throw "cannot BASE64 decode" on the base64 encoded ticket that the clients send.  My guess is it's related to the encode/decode changes that happened with the cyrus-sasl library and sendmail, but I haven't read up on the issues. Pulling down sendmail 8.14.3 from their website, compiling it, and using the same configuration results in successful GSSAPI negotiation.

Version-Release number of selected component (if applicable):

sendmail-8.13.8-8.el5

How reproducible:

Consistently.

Steps to Reproduce:
1. Configure sendmail for GSSAPI
2. Get a kerberos ticket on the client machine.
3. Attempt to auth via GSSAPI
  
Actual results:

Sendmail throws:

501 5.5.4 cannot BASE64 decode <LONG BASE64 STRING>
AUTH decode64 error [1 for <LONG BASE64 STRING>

Expected results:

Successful authentication.
Comment 1 melson 2010-05-09 19:04:19 EDT
Created attachment 412683 [details]
simple maxinpline patch

Looking deeper into it, it looks like this was fixed in Sendmail 8.14.1.  It's less BASE64 decoding and more the AUTH procedure running against the defined MAXLINE.  This is a simple patch that implements what looks to have been done in 8.14.1 that works in my environment. (Not sure where to look to find the patch actually applied to sendmail)
Comment 2 melson 2010-05-09 19:07:45 EDT
Created attachment 412684 [details]
maxinpline patch w/ auth sanity check included

Adding this one which, while more complicated, implements a sanity check on length commands (found in sendmail 8.14.3) that I suspect was implemented when MAXINPLINE was as well - this also works in my environment (though admittedly I've not done extensive testing).
Comment 3 RHEL Product and Program Management 2011-01-11 15:31:27 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 4 RHEL Product and Program Management 2011-01-12 10:09:24 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 5 RHEL Product and Program Management 2011-05-31 09:24:16 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 6 RHEL Product and Program Management 2011-09-22 20:13:59 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 7 RHEL Product and Program Management 2012-06-11 21:05:03 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 8 Jaroslav Škarvada 2013-03-06 07:59:03 EST
Red Hat Enterprise Linux 5 entered Production 2 phase. The focus for minor releases during this phase lies on resolving urgent or high priority bugs. For more details see https://access.redhat.com/support/policy/updates/errata/. As this bug is not qualified as urgent or high priority it is closed with resolution WONTFIX. This issue is already fixed in Red Hat Enterprise Linux 6. If this issue is critical for your business you can escalate it through the support channel (http://www.redhat.com/support/).

Note You need to log in before you can comment on or make changes to this bug.