[389-users] Announcing 389 Directory Server 1.2.6 Release Candidate 3

[Aaron Hagopian]

I filed a bug per Rich: https://bugzilla.redhat.com/show_bug.cgi?id=616206
<https://bugzilla.redhat.com/post_bug.cgi>

> How did you create the ldif file in
> "/var/lib/dirsrv/slapd-<instance>/ldif/"?  Did you move the ldif file there
> from elsewhere on your system?  That could explain why your ldif file has an
> incorrect context of "var_t".
>

Yes I moved the file there from another location.  I was just trying to see
if there is some acceptable directory.


>
> Try creating a new file in "/var/lib/dirsrv/slapd-<instance>/ldif/" using
> 'touch', then run 'ls -lZ' to see what the SELinux context is on that new
> file.  It should be "dirsrv_var_lib_t".
>

Yes creating a new file in that directory gets dirsrv_var_lib_t.  I did get
it in once I was able to get my file to have that SELinux attribute.  The
ldif file was created on my production server which is running 1.2.5.

I can't say I know that much about SELinux but I imagine this may become a
problem for people upgrading to 1.2.6 who want to start fresh?  Maybe can
the db2ldif.pl utility add that SELinux attribute?  Although that seems like
it would go against the point of SELinux if things can just add attributes
as needed.  Does the file not have the attribute because it was created in
1.2.5 or was it because on my production machine, when I created the file
(using db2ldif.pl), I saved it to a directory other than the SELinux one?
 It looks like when I run the db2ldif.pl command on my 1.2.6 machine it does
add some SELinux attributes.

I think the main reason I don't use the
/var/lib/dirsrv/slapd-<instance>/ldif/ file for my backups in the first
place is because by default the "nobody" user cannot write to that
directory.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20100719/bef93e55/attachment.html>