Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow database probing if _db_backend is not set #1451

Merged
merged 1 commit into from Dec 7, 2020

Conversation

mlschroe
Copy link
Contributor

@mlschroe mlschroe commented Dec 1, 2020

There is no harm in allowing read access in this case. We still
error out in the database rebuild case, just to be on the safe
side.

@mlschroe
Copy link
Contributor Author

mlschroe commented Dec 1, 2020

In case you're wondering where this is coming from: libsolv's rpmdb2solv currently does not work anymore because it does not read in the rpm macros.
I'm aware that this is a somewhat unsupported way of operating with librpm, but maybe the change is small enough so that you'll merge it anyway ;)

@pmatilai
Copy link
Member

pmatilai commented Dec 1, 2020

I've no problem allowing probing for read-only mode now that it wont go and create new databases in that mode, but I don't think we should ever write based on guessing. Change this to test for read-only dbmode and I'll happily merge. That should work for rpmdb2solv I think...

@mlschroe
Copy link
Contributor Author

mlschroe commented Dec 2, 2020

But is that really a problem? If it detects a known database type, writing should stay with the type anyway, so it's not wrong to also do this for a misconfigured database type.

And if it doesn't detect a known database type, it'll use dummydb like before.

@mlschroe
Copy link
Contributor Author

mlschroe commented Dec 2, 2020

Anyway, as it is so simple to test for readonlyness I added the check.

lib/backend/dbi.c Outdated Show resolved Hide resolved
@@ -77,7 +78,7 @@ dbDetectBackend(rpmdb rdb)
}
}

if (!cfg) {
if (!cfg && ((rdb->db_mode & O_ACCMODE) != O_RDONLY || (rdb->db_flags & RPMDB_FLAG_REBUILD) != 0)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, does this actually need the REBUILD flag test at all, with the O_RDONLY check in place?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not for rpm itself, but I think it should stay to guard against bad librpm users. Otherwise it'll crash with a null pointer deref below in the REBUILD case when trying to print the warning message.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that's no longer the case in this latest version, right?
There are quite a few important and subtle checks here so I think we shouldn't mix it up with any redundant ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will no longer crash, but it's still wrong. IMHO it's better to error out early when opening the old database in rebuilddb mode instead of later when opening the new database.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, fair enough.

There is no harm in allowing read access in this case. We still
error out in the database rebuild case, just to be on the safe
side. We now have the following logic:

_db_backend unset:
  * error out for rebuilddb or read-write access
  * use detected backend and print a debug message
_db_backend unknown:
  * error out for rebuilddb or read-write access
  * use detected backend and print a warning message
_db_backend set:
  * use detected backend and print a warning message if it
    does not match the configured backend
@mlschroe
Copy link
Contributor Author

mlschroe commented Dec 4, 2020

Ok, updated the pull request.

@pmatilai pmatilai merged commit 0644e4e into rpm-software-management:master Dec 7, 2020
@mlschroe
Copy link
Contributor Author

mlschroe commented Dec 7, 2020

Thank you! Could you please also cherry pick this into 4.16.1?

@pmatilai
Copy link
Member

pmatilai commented Dec 7, 2020

Sure - done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants