#49665 Upgrade script doesn't enable PBKDF password storage plug-in
Closed: wontfix 4 years ago Opened 4 years ago by mreynolds.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1576485

Description of problem:
If RHDS was installed using version 10.1.0 or earlier and you later upgrade to
RHDS 10.1.1 or 10.2, the upgrade script does not enable the PBKDF plug-in. Also
manually running "setup-ds.pl --update" (online and offline) mode doesn't fix
the problem.



Version-Release number of selected component (if applicable):
389-ds-base-1.3.7.5-19.el7_5.x86_64



Steps to Reproduce:
1. Install RHDS 10.1.0 (or earlier)
2. Use yum to update to the latest version
3. Try using the storage scheme.



Actual results:
cn=PBKDF2_SHA256,cn=Password Storage Schemes,cn=plugins,cn=config doesn't exist
and you also can't use the password storage scheme:

# ldapmodify -D "cn=Directory Manager" -w password -x
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: PBKDF2_SHA256

modifying entry "cn=config"
ldap_modify: Operations error (1)
        additional info: passwordStorageScheme: invalid scheme - PBKDF2_SHA256.
Valid schemes are: CLEAR, CRYPT, MD5, SHA, SHA256, SHA384, SHA512, SMD5, SSHA,
SSHA256, SSHA384, SSHA512



Expected results:
cn=PBKDF2_SHA256,cn=Password Storage Schemes,cn=plugins,cn=config should exist
and users should be able to use the password storage scheme.



Additional info:
I tried this on a machine which was initially installed with 1.3.5, then
upgraded to several 1.3.6 version, and recently to 1.3.7:
Jun 14 09:50:11 Installed: 389-ds-base-1.3.5.10-21.el7_3.x86_64
Aug 02 08:49:52 Updated: 389-ds-base-1.3.6.1-16.el7.x86_64
Oct 16 18:02:08 Updated: 389-ds-base-1.3.6.1-19.el7_4.x86_64
Nov 10 14:28:09 Updated: 389-ds-base-1.3.6.1-21.el7_4.x86_64
Dec 04 13:59:03 Updated: 389-ds-base-1.3.6.1-24.el7_4.x86_64
Feb 01 13:13:14 Updated: 389-ds-base-1.3.6.1-26.el7_4.x86_64
Apr 10 10:42:54 Updated: 389-ds-base-1.3.7.5-18.el7.x86_64
Apr 10 11:00:44 Updated: 389-ds-base-1.3.7.5-19.el7_5.x86_64
None of these updates enabled the plug-in.

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1576485

4 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

4 years ago

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue set to the milestone: 1.3.6.0 (was: 0.0 NEEDS_TRIAGE)

4 years ago

The new CRYPT schemes are also not added during upgrade

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: None)

4 years ago

I did upgrade from 1.3.5 to 1.3.6 and from 1.3.6 to 1.3.7. New plugins are successfully added - ack.

Metadata Update from @vashirov:
- Custom field reviewstatus adjusted to ack (was: review)

4 years ago

5bf4fd5..91dc832 master -> master

90ca2eb..89a9de9 389-ds-base-1.3.8 -> 389-ds-base-1.3.8

f30e15c..55cce82 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

d495def..a8a94b3 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Hi @mreynolds. I think you don't need this, and should revert it.

For a start, on 1.3.x series you can't use pbkdf2 because EL doesn't support it in NSS. It won't work!

Second, there is a start up upgrade mechanism for this in 1.4.x. See this part of fedse.c.

https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/fedse.c#_54

I'd like to ask you to revert this patch, and move these changes to fedse.c.

A really important reason is containers. You can't guarantee that rpm post scripts will ever be run in a container. Another one is a restore from backup.

The only way to guarantee this is added is at start up, and you check it's there.

Ohh and PS: The new python installer and tools have no concept of upgrade scripts for this reason, and they never should. All "upgrade scripts" should be part of the server core, and even the certmap patch has steps for this. So please consider that upgrades are a server internal feature, not a "script". The server has to be completely self hosting.

Hi @mreynolds. I think you don't need this, and should revert it.
For a start, on 1.3.x series you can't use pbkdf2 because EL doesn't support it in NSS. It won't work!

You added pbkdf2 to 1.3.6! It's already downstream in RHEL 7. So now we have to deal with this upgrade problem.

Second, there is a start up upgrade mechanism for this in 1.4.x. See this part of fedse.c.

I did see that this was working on master...

https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/fedse.c#_54
I'd like to ask you to revert this patch, and move these changes to fedse.c.

This is nice and I will make sure to use this moving forward, but like you said this is working 1.4.x. This fix is for people moving from 1.3.5 or 1.3.6. to 1.3.7(1.3.8). So yeah, sorry, this should not have been committed to "master", but it's needed in the other branches. I'm weary about making any big changes to 1.3.8 in regards to fedse.c. This would be an RFE to me, and we are keeping 1.3.x bug fix only (trying to focus on 1.4.0). We aren't supporting containers in 1.3.x anyway so the upgrade scripts are still valid in 1.3.x.

Okay, so, in master branch I will remove the upgrade script and move that functionality to fedse.c. Looks like it's only needed for the new CRYPT schemes...

Reopening and changing milestone to 1.4.0

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.0 (was: 1.3.6.0)
- Issue status updated to: Open (was: Closed)

4 years ago

Hi @mreynolds. I think you don't need this, and should revert it.
For a start, on 1.3.x series you can't use pbkdf2 because EL doesn't support it in NSS. It won't work!

You added pbkdf2 to 1.3.6! It's already downstream in RHEL 7. So now we have to deal with this upgrade problem.

Yes, because it worked on fedora at the time and I needed to develop it. It was never meant to be enabled on RHEL because NSS wouldn't support it.

Second, there is a start up upgrade mechanism for this in 1.4.x. See this part of fedse.c.

I did see that this was working on master...

https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/fedse.c#_54
I'd like to ask you to revert this patch, and move these changes to fedse.c.

This is nice and I will make sure to use this moving forward, but like you said this is working 1.4.x. This fix is for people moving from 1.3.5 or 1.3.6. to 1.3.7(1.3.8). So yeah, sorry, this should not have been committed to "master", but it's needed in the other branches. I'm weary about making any big changes to 1.3.8 in regards to fedse.c. This would be an RFE to me, and we are keeping 1.3.x bug fix only (trying to focus on 1.4.0). We aren't supporting containers in 1.3.x anyway so the upgrade scripts are still valid in 1.3.x.
Okay, so, in master branch I will remove the upgrade script and move that functionality to fedse.c. Looks like it's only needed for the new CRYPT schemes...
Reopening and changing milestone to 1.4.0

Okay. That's a good compromise. Sorry for the hassle.

  • upgrade script for 1.3.x
  • crypt plugins in fedse.c for 1.4.x (and no upgrade script).

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: ack)

4 years ago

Metadata Update from @tbordaz:
- Custom field reviewstatus adjusted to ack (was: review)

4 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2724

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

2 years ago

Login to comment on this ticket.

Metadata