Bug 616206

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.

(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....

(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

Is this a bug?  A documentation issue?  How can we resolve this bug?

(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.

Has this work been done?  Can we close this bug?

Yes, this is being taken care of in the RHDS 9.0 Administration Guide.  We can close this bug.