I'll do my best to try and explain the problem here. For future reference a quick email to the
fedora-selinux, or NSA SELinux mailing lists will probably save you a lot of time and headache
and usually gets a quick reply.
The issue here is that a symlink is not the same as a directory. In the Linux DAC model
everything is treated the same. A file/directory/symlink etc.. all only have permissions based
on the traditional Unix permission bits. So there is no different between the file and a
symlink to the file because in the end the symlink will just resolve to that file anyway. In
SELinux we make a distinction between the many types of objects in the system. Files,
Directories, Sockets, Pipes, Symlinks, etc all are different and while some may share
permissions they aren't the same permission. So let's consider what happened in your case. The
policy says that postgres has the ability to look in a directory labeled a certain way and
read files labeled a certain way. All of a sudden what the program once thought was a
directory is now a symlink. Normally this isn't an issue because it will be resolved, however
chances are the link does not have the proper label and the policy isn't allowed to follow
symlinks of that type. For this reason SELinux blocks the access. You can probably imagine
several ways that symlinks can be used to trick postgres into doing something that wasn't
intended so this is a resonable security precaution.
There are two solutions to this problem.
1) Label the symlink correctly and if postgres isn't allowed to follow symlinks of that type
create a loadable policy module to allow it. This is a little more advanced for a regular user
and might be more than they are willing to do.
2) Bind mount the directory. Since bind mounts are just namespace manipulation even though the
directory is pointing somewhere else it is still a directory and it is still labeled with the
appropriate label. This is a much better solution since it won't require any policy
In either of these steps it helps to add an entry using semanage for file_contexts to say that
the files under your new location keep a certain label on relabeling. This is normally taken
care of for you if everything is in the default location but since you have moved it if you
perform a system relabel it could steamroll your labels.
Hopefully this explained what was going on and will help you when you want to move things into
non-standard directories in the future. This and a bunch more information will eventually make
its way to selinuxproject.org