Hi,

(In reply to Matej Mužila from comment #4)
> Workaround to this problem is to run db_hotbackup not by user root but by
> user ldap.
Thank you, we in support are aware, and this is also documented in the linked kbase article.  
This is however not preventing the customer though to run the backup with a different user.  This bz is to get more bulletproof tools and lower chances that people have to experience the issue first while running as incorrect user, risking loss of data and waste of time, before they understand that they use the incorrect user.  Checking this in the tool should be simple, and the gains are huge.

(In reply to Matej Mužila from comment #7)
> I'm afraid that there is no bulletproof way to get the owner of database.
> For example when the database is not initialized, there are no files that
> could be used to determine owner of the database.
Yes, we are not worried about that case here as the files do not exist.  Whoever executes the backup then and has write permissions can write the first backup (excluding unlikely things like disk full etc.).
 
> Even if there are database files present, determining owner of the database
> from them is a bit tricky. 
Do you mean the database files?  If the filesystem is aware of ownerships, we should be able to see who owns the file?

> There may exist a situation, where database files
> are not owned by user that runs the database.
To my understanding, the requirement is that the db_hotbackup is executed as the same user who owns the files, correct?
If that is the case, shouldn't we just need 
a) the user-id under which db_hotbackup is started
b) the owner of the existing files
and then compare these?

> Determining the right user from a previous log file is insufficient, because
> previous log file may be nonexistent.
Yes, but I think it's ok to not consider that situation.

(In reply to Matej Mužila from comment #10)
> (In reply to Christian Horn from comment #8)
> > > Even if there are database files present, determining owner of
> > > the database
> > > from them is a bit tricky. 
> > Do you mean the database files?  If the filesystem is aware of ownerships,
> > we should be able to see who owns the file?
> 
> Yes, we are able to find out who owns those files, but imagine a situation
> when files are not owned by the user that runs database. They may be owned
> by different user and have set read/write permissions to a group or anybody.
> This is obviously not the case of ldap, however ldap is not the only thing
> that uses libdb.

I think you refer to the situation which we want to make more bulletproof with this bz.  Saying it in pseudo-code:

if (no databasefiles do yet exist) {
  just write the files with the permissions of the user
  executing the db_hotbackup script
}
else {
  if ( (user who started db_hotbackup) == (user who owns existing files) ) {
    just do the backup, permissions seem to be in order.
  }
  else {
    do some appropriate(tm) action.
    - For example, if started as root, write files as user who owns
      existing files.
    - or atleast output a big fat warning message if this situation
      is detected
    optional: blindly try to write the backup files anyway,
    this is the action we currently undertake.
  }
}


> > To my understanding, the requirement is that the db_hotbackup is executed as
> > the same user who owns the files, correct?
> > If that is the case, shouldn't we just need 
> > a) the user-id under which db_hotbackup is started
> > b) the owner of the existing files
> > and then compare these?
> 
> db_hotbackup should be ran by the same user, that runs database (in this
> case user ldap).

Agreed.  The request in this bz is to better deal with the situation
when that is not the case.  Even outputting "this looks fishy, the 
user who started the script does not own existing backup files" would
help.


> > > Determining the right user from a previous log file is
> > > insufficient, because
> > > previous log file may be nonexistent.
> > Yes, but I think it's ok to not consider that situation.
> 
> I don't think so. This situation is real and may occur. I think that making
> db_hotbackup to "guess" the right user is much worse than not doing so, if
> it is impossible to do so in all cases. It would make usage of db_hotbackup
> even less predictable and tricky than it is now.

I have not understood the situation here referred to well enough to comment, I can not imagine a situation where we have to guess.  Getting less predictable is not good of course.  How about just trying to detect the situation then and additionally to what we currently do (simply trying to write the files) additionally outputting a warning?

(In reply to Matej Mužila from comment #12)
> We may print warning when we detect potentially dangerous situation (user
> different to user owning files). Most of dangerous situations would be
> detected (and announced to admin) and behavior of db_hotbackup would not
> change.
> 
> What do you think about it?

Great, lets do that.

(In reply to Matej Mužila from comment #16)
> We think, it would be better to mention in man page, that if db_hotbackup
> is run with -c parameter, it is necessary to run it by the user that owns
> databse files.
> 
> The other thing is that the problem occurs quite rarely (1 of 40 000 cases)
> and it is not caused by the program itsefl, but by running the program
> incorrectly.
> 
> Do you think it is OK?

Customer will continue to run into this, and just then when having run into the issue investigate and hit the error description - so warning would be beneficial over just documenting, IMHO.
We have to take only documentation if we are not getting the warning, though.  We have this in kbase for customers, having it in the manpage will document it for all users.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0952