Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 616206 - SELinux issue while running ldif2db.pl
SELinux issue while running ldif2db.pl
Status: CLOSED NOTABUG
Product: 389
Classification: Retired
Component: Command Line Utilities (Show other bugs)
1.2.6
All Linux
low Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-19 16:22 EDT by Aaron Hagopian
Modified: 2015-01-04 18:43 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-29 15:19:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aaron Hagopian 2010-07-19 16:22:50 EDT
Description of problem:

Cannot load a file using ldif2db.pl because of SELinux restriction

Version-Release number of selected component (if applicable):

1.2.6 RC3 
Fedora 13 X86_64 (updates-testing repo)

On my workstation to sync up my ldap server with production I take a ldif dump from production and load it into my system with the ldif2db.pl script.  For versions 1.2.5 and previous that ldif file could be located anywhere that was readable to the "nobody" user.  Since upgrading, I try to use the same command and get denied because of SELinux.  

My real question here is what is an acceptable directory?  I thought for sure the /var/lib/dirsrv/slapd-<instance>/ldif/  directory would be acceptable but I get a "SELinux is preventing /usr/sbin/ns-slapd "read" access on ..." message no matter where I place the LDIF file.

The LDIF file was creating in 1.2.5 so it seems like it is missing the dirsrv_var_lib_t SELinux attribute.
Comment 1 Nathan Kinder 2010-07-19 16:56:41 EDT
The "/var/lib/dirsrv/slapd-<instance>/ldif/" directory is the correct place.  If the LDIF file was in place there prior to upgrading to 389 1.2.6, it should have been labelled appropriately when you upgraded to 389 1.2.6.  If it was located somewhere else on your system, it may not have been relabelled properly.

If you create a new file with the 'touch' command in your "/var/lib/dirsrv/slapd-<instance>/ldif/" directory, what SELinux context is it created with?  You can check the context with 'ls -lZ'.

Where was your LDIF file prior to upgrading to 389 1.2.6?  If it was somewhere other than your instances "ldif" directory, did you move it or copy it into the "ldif" directory?  When you move a file, it's existing context is kept, so that could explain how you have the wrong label on your LDIF file.
Comment 3 Aaron Hagopian 2010-07-21 10:42:43 EDT
(In reply to comment #1)
> The "/var/lib/dirsrv/slapd-<instance>/ldif/" directory is the correct place. 
> If the LDIF file was in place there prior to upgrading to 389 1.2.6, it should
> have been labelled appropriately when you upgraded to 389 1.2.6.  If it was
> located somewhere else on your system, it may not have been relabelled
> properly.
> 

As I mentioned on the mailing list this is not the directory I use.  This mostly has to do with the fact that I have been running fedora-ds 1.0 on this machine for years and wrote a cron job that dumps the file to /var/backups/ which is where I have a few other server's dumping their files as well.

When I upgraded to 1.2.5 I did try to change to the "/var/lib/dirsrv/slapd-<instance>/ldif/" directory but it failed because of access denied to the nobody user.  Would you recommend allowing the nobody user to write to that directory?  

> If you create a new file with the 'touch' command in your
> "/var/lib/dirsrv/slapd-<instance>/ldif/" directory, what SELinux context is it
> created with?  You can check the context with 'ls -lZ'.

Yes when I create a file in this directory it does seem to get the correct security context and I was able to load files with the correct security context.

> 
> Where was your LDIF file prior to upgrading to 389 1.2.6?  If it was somewhere
> other than your instances "ldif" directory, did you move it or copy it into the
> "ldif" directory?  When you move a file, it's existing context is kept, so that
> could explain how you have the wrong label on your LDIF file.    

As I mentioned before we currently use /var/backups/ for these files.  We gzip the backup file on the production server as part of the cron job.  Then on my development machine I rsync the gzipped file over to the same directory on my machine /var/backups, unzip the file and run the ldif2db.pl.  

So I think the first real problem is that when I unzip the file, depending on where I unzip the file is part of the issue.  When I unzip the file in /var/backups it gets a different security context and cannot be loaded.  When I unzip it in the "/var/lib/dirsrv/slapd-<instance>/ldif/" directory it gets the correct context (being a new file).

So the real bug to me here is that you cannot run the db2ldif.pl file and have it output to the "/var/lib/dirsrv/slapd-<instance>/ldif/" directory, which is the recommended directory for this. 

As for the loading part, now that I understand the process, I will update my scripts that update my development environment to unzip and load from the correct directory.  Maybe the scripts themselves may want to mention in the help if SELinux is enabled then....
Comment 4 Nathan Kinder 2010-07-22 18:20:21 EDT
(In reply to comment #3)
> When I upgraded to 1.2.5 I did try to change to the
> "/var/lib/dirsrv/slapd-<instance>/ldif/" directory but it failed because of
> access denied to the nobody user.  Would you recommend allowing the nobody user
> to write to that directory?  
> 

The ldif directory should be writeable by the user that ns-slapd runs as.  I have confirmed that the permissions on the "/var/lib/dirsrv/slapd-<instance>/ldif" directory are set as 770 for my user/group that ns-slapd is configured to run as with a fresh install.  Perhaps this issue has to do with the fact that you have upgraded from older fedora-ds versions that had different ownership/permissions.

[root@boraras ~]# ps -ef | grep slapd
nobody   27467     1  1 15:16 ?        00:00:00 ./ns-slapd -D /etc/dirsrv/slapd-foo -i /var/run/dirsrv/slapd-foo.pid -w /var/run/dirsrv/slapd-foo.startpid
root     27533 27335  0 15:16 pts/5    00:00:00 grep slapd

[root@boraras ~]# ls -l /var/lib/dirsrv/slapd-foo/
total 12
drwxrwx---. 2 nobody nobody 4096 2010-07-22 15:16 bak
drwxrwx---. 3 nobody nobody 4096 2010-07-22 15:16 db
drwxrwx---. 2 nobody nobody 4096 2010-07-22 15:16 ldif
Comment 5 Rich Megginson 2010-08-04 17:38:02 EDT
Is this a bug?  A documentation issue?  How can we resolve this bug?
Comment 6 Nathan Kinder 2010-08-04 17:43:58 EDT
(In reply to comment #5)
> Is this a bug?  A documentation issue?  How can we resolve this bug?    

It may be an upgrade bug, but I'm just not sure at this point.  The permissions look correct to me with freshly created instances.

We do need to document the locations that should be used for all of the online tasks that read or write files (import/export and backup/restore mainly) when using SELinux.  This is a more general purpose task that is on our to-do list.
Comment 7 Rich Megginson 2011-08-29 12:29:57 EDT
Has this work been done?  Can we close this bug?
Comment 8 Nathan Kinder 2011-08-29 15:19:07 EDT
Yes, this is being taken care of in the RHDS 9.0 Administration Guide.  We can close this bug.

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