Assuming <filename> is not a full path, 1) db2ldif -a <filename> tries to create the file in /usr/sbin, which usually fails since the server user ("nobody" by default) does not have the right to write in /usr/sbin. 2) db2ldif.pl -a <filename> creates the file in the log directory /var/log/dirsrv/slapd-ID, which is not expected.
The exported file is supposed to be placed in the current directory where the command-line is executed if "-a <filename>" is specified.
Thanks to Asha for reporting the bug.
Bug description: If -a "filename" is given to db2ldif or db2ldif.pl and it is not a full path representation, the file is not created in the location relative to the current working directory.
Fix description: This patch gets the current working directory in the both utilities, and completes the path relative to the current working directory.
git patch file (master) 0001-Ticket-585-Behaviours-of-db2ldif-a-filename-and-db2l.patch
Does this work properly with SELinux for both cases? For the db2ldif.pl case, I would think we don't necessarily have the ability to write to the current working directory due to policy.
Replying to [comment:3 nkinder]:
Does this work properly with SELinux for both cases? Well, with the current implementation, even if I run the utilities in the directory which is supposed to be allowed (e.g., /var/lib/dirsrv/slapd-ID/ldif) fails... {{{
/var/lib/dirsrv/slapd-ID/ldif
Exported ldif file: exported.ldif ldiffile: exported.ldif [..] - db2ldif: can't open exported.ldif: 13 (Permission denied) [..] - All database threads now stopped }}}
For the db2ldif.pl case, I would think we don't necessarily have the ability to write to the current working directory due to policy.
If a customer hopes to set a SELinux policy on some arbitrary place, then we'd better allow exporting the db contents to the location? Currently, it's not working unless you pass a full path...
Also I'm very close to sending out my total script rewrite(Ticket 528). Could you hold off on this until I commit that change(since its a total rewrite) - I'm afraid my change might not merge cleanly with your change.
Thanks, Mark
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=918718
Noriko, all the new script work is done. Can you re-work this fix in the new scripts?
git patch file (master) 0001-Ticket-585-Behaviours-of-db2ldif-a-filename-and-db2l.2.patch
Reviewed by Rich (Thanks!!)
Pushed to master: commit 9195857
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.1
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/585
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.