Bug 1788543 - Removing libdb dependency from pam
Summary: Removing libdb dependency from pam
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Iker Pedrosa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1778802
TreeView+ depends on / blocked
 
Reported: 2020-01-07 13:29 UTC by Filip Januš
Modified: 2024-02-19 08:17 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-02-19 08:17:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SSSD-3461 0 None None None 2022-02-03 13:19:52 UTC
Red Hat Issue Tracker SSSD-6503 0 None None None 2023-10-07 09:58:58 UTC

Description Filip Januš 2020-01-07 13:29:36 UTC
According to more restrictive libdb licence policy exists effort to remove libdb's dependencies.
Pam package is now built with libdb requirement, this package should supports also NDBM databases(./configure --enable-db=(db|ndbm|yes|no)). GDBM supports NDBM, so GDBM could be good alternative.

Comment 1 Tomas Mraz 2020-01-07 13:44:50 UTC
What does it mean for existing databases? Do they have to be converted?

Comment 2 Filip Januš 2020-01-07 14:39:32 UTC
Conversion would be the best solution. Because effort is try to remove libdb from Fedora 33. Nowadays I am investigating opportunities of changing databases of dependent packages on libdb. In response I would like to propose some converting utility.
The other choice is change default database to NDBM and holds libdb support in Fedora for backward compatibility until everyone will use NDBM.

Comment 3 Filip Januš 2020-11-24 09:43:17 UTC
We would like to move a step forward by getting rid of libdb. So I would like to ask, which problems do you see with changing backend from BDB to some other database(probably conversion is needed,...)? I want to summarize as much as possible problems with this change across components, so we can find the best possible solution.

Comment 4 Iker Pedrosa 2020-11-24 11:13:41 UTC
The biggest concern is around database conversion and how it will be handled. What's your exact proposal? Change the default database to NDBM? Do you plan on changing it when a new Fedora version is released or in existing versions? In any case, when will the conversion take place? Which team do you think should take charge of the conversion tool?

Finally, IIUC pam is already supporting NDBM. Thus, libdb dependency could be change by gdbm and from the pam point of view everything would be ready. Am i right?

Comment 5 Filip Januš 2020-11-24 14:23:53 UTC
It should be part of new Fedora release of course (Fedora change is needed), which one Fedora isn't clear yet, because it affects a lot of components. New default database should be ideally present in Fedora, which one do you prefer?  The conversion tool should be in charge of our team because some type of conversion is necessary for more components. Now arise questions about conversion, when would be the right place for conversion(during fedora update?)? What about database locations? Are there default paths to databases or it could be changed by users? if so where to find the right locations? Or exists some easier way how to create a new pam database? (My knowledge of pam isn't so good, but some other component can regenerate the database from configuration files and conversion isn't necessary..)

regarding your last question, yes it's our purpose, to change the backend database without impact on users.

Comment 6 Iker Pedrosa 2020-11-25 11:07:44 UTC
Apart from libdb the other option for a database is NDBM so we could stick with it.

As for when would be a good time for conversion, it doesn't have a straightforward answer. There isn't any default place for the database, so it could be anywhere. The only way of knowing where it's located is to parse pam stack files and check if pam_userdb module is used somewhere. If it is, then one of the options must be the location for the database (db=). Thus, when upgrading a search for pam_userdb in /etc/pam.d/ needs to be executed, and either the database is automatically converted or the upgrade fails indicating that the database has to be converted manually. If RHEL9 is going to change the database then the last option would be preferable. As you can see it's not as easy as it seems. Besides, default Fedora and RHEL installations don't use pam_userdb.

Comment 7 Vít Ondruch 2023-10-30 17:10:47 UTC
I wonder, what is the purpose of `Requires: libdb-convert-util` in:

https://src.fedoraproject.org/rpms/pam/c/557fe26951bab5103a94b7048ba32cb716aecb99?branch=rawhide

Just doing quick search over pam GH repo, I can't see any reference to `db_converter`, which is the only tool provided by the libdb-convert-util package.

Comment 8 Iker Pedrosa 2023-10-31 08:48:29 UTC
`db_converter` is the tool that will convert the pam_userdb database from BerkeleyDB to GDBM. As explained in the Fedora System-Wide Change [1], it needs to be run manually to convert the database. That's why you can't find any reference to it in the PAM repo.

Even if it's run manually, the tool is still needed and that's why I'm adding the dependency.

Links:
[1] https://fedoraproject.org/wiki/Changes/PamBerkeleyDBtoGdbm

Comment 9 Vít Ondruch 2023-10-31 12:29:09 UTC
(In reply to Iker Pedrosa from comment #8)
> `db_converter` is the tool that will convert the pam_userdb database from
> BerkeleyDB to GDBM. As explained in the Fedora System-Wide Change [1], it
> needs to be run manually to convert the database. That's why you can't find
> any reference to it in the PAM repo.
> 
> Even if it's run manually, the tool is still needed and that's why I'm
> adding the dependency.

Do I need this tool as a regular user? I don't think so. I don't even know what `pam_userdb` is.

If I needed it, I doubt it would be more then once.

I'm sorry but I can't see the reason for the `Requires`. I don't think that even `Recommends` would be justifiable, but at least it would enable to remove `libdb-convert-util` from the system once not needed.

Comment 10 Iker Pedrosa 2023-10-31 15:28:40 UTC
You are right in that a strong dependency isn't needed. I wonder if it wouldn't be more useful to add Suggests for this case. It's more of a hint, so it doesn't install any dependency but it suggests it.

Comment 11 Vít Ondruch 2023-10-31 17:15:46 UTC
(In reply to Iker Pedrosa from comment #10)
> You are right in that a strong dependency isn't needed. I wonder if it
> wouldn't be more useful to add Suggests for this case. It's more of a hint,
> so it doesn't install any dependency but it suggests it.

`Suggests` would be about ideal. Unfortunately, I don't think this data are presented to user in any meaningful way :( Maybe it is about a time to open RFE for DNF.

Comment 12 Vít Ondruch 2023-10-31 17:23:23 UTC
(In reply to Vít Ondruch from comment #11)
> Maybe it is about a time to open RFE for DNF.

https://github.com/rpm-software-management/dnf5/issues/992

Comment 13 Iker Pedrosa 2023-11-16 08:42:49 UTC
I see that issue stalled. Do you agree that the best way forward is to use "Suggests"?

Comment 14 Vít Ondruch 2023-11-21 09:15:52 UTC
(In reply to Iker Pedrosa from comment #13)
> I see that issue stalled. Do you agree that the best way forward is to use
> "Suggests"?

It is fine for me. I wish DNF provided better support for it ...


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