RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 863415 - Possible to add invalid attribute values to PAM PTA plugin configuration
Summary: Possible to add invalid attribute values to PAM PTA plugin configuration
Keywords:
Status: CLOSED DUPLICATE of bug 746642
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 7.0
Assignee: Rich Megginson
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-05 12:33 UTC by Ján Rusnačko
Modified: 2013-01-31 17:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-31 17:57:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ján Rusnačko 2012-10-05 12:33:05 UTC 
Description of problem:

PAM passthrough plugin now accepts even incorrect values for soome attributes in configuration entry, namely pamIDMapMethod, pamMissingSuffix and pamService. Invalid values can be passed to pamIDMapMethod (should allow only RDN DN ENTRY) and pamMissingSuffix (should allow only ALLOW IGNORE ERROR), while pamService accepts empty value. 

Version-Release number of selected component (if applicable):
389-ds-base-1.2.10.2-15.el6.x86_64

How reproducible:
always


Steps to Reproduce:
ldapmodify .. <<EOF
dn: cn=PAM Pass Through Auth,cn=plugins,cn=config
changetype: modify
replace: pamIDMapMethod
pamIDMapMethod: invalid
-
replace: pamMissingSuffix
pamMissingSuffix: invalid
-
replace: pamService
pamService: 
EOF
  
Actual results:
ldapmodify succeeds

Expected results:
Should fail with ldap_modify: Invalid syntax  (return code 21)

Additional info:
other attributes do not permit incorrect values and fail with RC 21, e.g. pamFallback or pamExcludeSuffix
Comment 2 Sankar Ramalingam 2012-10-08 14:16:28 UTC 
QA Acked.
Comment 3 Sankar Ramalingam 2012-10-08 14:38:46 UTC 
(In reply to comment #2)
> QA Acked.

Oops, sorry, by mistake added for this bug.
Comment 4 Rich Megginson 2012-10-08 15:14:00 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/487
Comment 8 thierry bordaz 2013-01-23 18:47:48 UTC 
Hi Jan,

  The test case expects a modify failure with the return code 21 (syntax error).
  This is right the modify should fail but with a return code 53 (unwilling to perform). In fact, from a syntax point of view all the modify are valid but the semantic should be rejected by the server. So "unwilling to perform" seems the appropriate code.

  Also this bug was discovered on 1.2.10 but fixed in 1.2.11 and later.

  The bug being fixed on master, do we keep this bug open until the test case is fixed ?
  
best regards
Comment 9 Rich Megginson 2013-01-23 19:22:45 UTC 
(In reply to comment #8)
> Hi Jan,
> 
>   The test case expects a modify failure with the return code 21 (syntax
> error).
>   This is right the modify should fail but with a return code 53 (unwilling
> to perform). In fact, from a syntax point of view all the modify are valid
> but the semantic should be rejected by the server. So "unwilling to perform"
> seems the appropriate code.
> 
>   Also this bug was discovered on 1.2.10 but fixed in 1.2.11 and later.

It was fixed in 1.2.11? I don't see that in https://fedorahosted.org/389/ticket/487

> 
>   The bug being fixed on master, do we keep this bug open until the test
> case is fixed ?


>   
> best regards
Comment 10 Nathan Kinder 2013-01-23 21:26:07 UTC 
(In reply to comment #9)
> It was fixed in 1.2.11? I don't see that in
> https://fedorahosted.org/389/ticket/487
> 

Proper configuration validation was added as a part of the multiple PAM Pass-through config enhancement in this upstream ticket:

    https://fedorahosted.org/389/ticket/181
Comment 11 Ján Rusnačko 2013-01-28 14:40:35 UTC 
(In reply to comment #8)
> Hi Jan,
> 
>   The test case expects a modify failure with the return code 21 (syntax
> error).
>   This is right the modify should fail but with a return code 53 (unwilling
> to perform). In fact, from a syntax point of view all the modify are valid
> but the semantic should be rejected by the server. So "unwilling to perform"
> seems the appropriate code.
> 
>   Also this bug was discovered on 1.2.10 but fixed in 1.2.11 and later.
> 
>   The bug being fixed on master, do we keep this bug open until the test
> case is fixed ?
>   
> best regards

Hi Thierry,

thank you for the fix and explanation. I have fixed testcase for this in trunk. I tried to verify this on RHEL64 with 389-ds-base-1.2.11.13-1.el6.x86_64 from latest-RHEL6.4-DSRV-9.0 repo, but fix is not there. Can you please check again to which version was this fix added ?

Thanks,
Jan
Comment 12 thierry bordaz 2013-01-30 13:10:02 UTC 
Hi Jan,

   I verified the original bug on RHEL 64 and 1.2.11.15-11.
   The bug is fixed in 1.2.11.15-11.

[thierry@rhel-63-1 /]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 Beta (Santiago)

[thierry@rhel-63-1 /]$ rpm -qa |grep 389
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-1.2.11.15-11.el6.x86_64
389-ds-base-libs-1.2.11.15-11.el6.x86_64
389-dsgw-1.1.9-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-adminutil-1.1.15-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-admin-1.1.29-1.el6.x86_64
389-admin-console-1.1.8-1.el6.noarch

[thierry@rhel-63-1 /]$ ldapmodify -h localhost -p 10478 -D "cn=directory manager" -w secret12
dn: cn=PAM Pass Through Auth,cn=plugins,cn=config
changetype: modify
replace: pamMissingSuffix
pamMissingSuffix: invalid

modifying entry "cn=PAM Pass Through Auth,cn=plugins,cn=config"
ldap_modify: Server is unwilling to perform (53)
        additional info: Error: valid values for pamMissingSuffix are PAMPT_MISSING_SUFFIX_ERROR, PAMPT_MISSING_SUFFIX_ALLOW, PAMPT_MISSING_SUFFIX_IGNORE


    You mentioned you tested (unsuccessfully) on 1.2.11.13.el6. I am surprised because so far I was thinking that the bug fix which fixed this issue (https://bugzilla.redhat.com/show_bug.cgi?id=746642) was introduced in 1.2.11.12
    I do not know how to install 1.2.11.13.el6 on top of RHEL6.4 as 'yum install 389-ds' installed 1.2.11.15-11


best regards
Comment 13 Ján Rusnačko 2013-01-31 10:35:02 UTC 
Hi Thierry,

this is what it looks like on my machine (actually, on both that I checked):

[jrusnack@dstet ~]$ rpm -qa 389*
389-ds-base-1.2.11.15-11.el6.x86_64
389-ds-base-libs-1.2.11.15-11.el6.x86_64
[jrusnack@dstet ~]$ service dirsrv status
dirsrv dstet (pid 2780) is running...
[jrusnack@dstet ~]$ 
[jrusnack@dstet ~]$ ldapmodify -h localhost -p 22222 -D "cn=directory manager" -w Secret123 <<EOF
> dn: cn=PAM Pass Through Auth,cn=plugins,cn=config
> changetype: modify
> replace: pamMissingSuffix
> pamMissingSuffix: invalid
> EOF
modifying entry "cn=PAM Pass Through Auth,cn=plugins,cn=config"

[jrusnack@dstet ~]$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.4 Beta (Santiago)

Reinstall didn`t help. I will investigate further.

1.2.11.13.el6 is from latest-RHEL6.4-DSRV-9.0 repo, which IIRC is supposed to be closer to main RHEL 6.4 devel branch than official one.
Comment 14 Ján Rusnačko 2013-01-31 11:05:15 UTC 
Ok, got it. Since the plugin was disabled, error messages were correctly logged to error log. 

[31/Jan/2013:05:45:18 -0500] - 389-Directory/1.2.11.15 B2013.021.196 starting up
[31/Jan/2013:05:45:18 -0500] pam_passthru-plugin - Error: valid values for pamMissingSuffix are PAMPT_MISSING_SUFFIX_ERROR, PAMPT_MISSING_SUFFIX_ALLOW, PAMPT_MISSING_SUFFIX_IGNORE
[31/Jan/2013:05:45:19 -0500] pam_passthru-plugin - pam_passthru_load_config: skipping invalid config entry "cn=pam pass through auth,cn=plugins,cn=config"

[jrusnack@dstet ~]$ ldapmodify -h localhost -p 22222 -D "cn=directory manager" -w Secret123 <<EOF
dn:  cn=PAM Pass Through Auth,cn=plugins,cn=config
changetype: modify
replace: pamMissingSuffix
pamMissingSuffix: invalid
EOF
modifying entry "cn=PAM Pass Through Auth,cn=plugins,cn=config"
ldap_modify: Server is unwilling to perform (53)
	additional info: Error: valid values for pamMissingSuffix are PAMPT_MISSING_SUFFIX_ERROR, PAMPT_MISSING_SUFFIX_ALLOW, PAMPT_MISSING_SUFFIX_IGNORE

[jrusnack@dstet ~]$ ldapmodify -h localhost -p 22222 -D "cn=directory manager" -w Secret123 <<EOF
dn:  cn=PAM Pass Through Auth,cn=plugins,cn=config
changetype: modify
replace: pamIDMapMethod
pamIDMapMethod: invalid
EOF
modifying entry "cn=PAM Pass Through Auth,cn=plugins,cn=config"
ldap_modify: Server is unwilling to perform (53)
	additional info: The map method in the string [invalid] is invalid: must be one of DN or RDN or ENTRY
Note You need to log in before you can comment on or make changes to this bug.