Re: COPY - permission denied

On 9/23/05, John Seberg <johnseberg(at)yahoo(dot)com> wrote:
>
> --- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > John Seberg <johnseberg(at)yahoo(dot)com> writes:
> > > I have used the COPY command dozens of times! I
> > think
> > > I *get* it. But, I'm getting "permission denied"
> > > errors.
> >
> > > This is a fresh install of Fedora Core 4 (x86). I
> > have
> > > Postgresql running under the user postgres. I am
> > > logged into to psql as postgres. The files are
> > owned
> > > by postgres and are -rw-------. They are being
> > found -
> > > it isn't a "file not found" error.
> >
> > Do you have SELinux running in enforcement mode? If
> > so, it's likely
> > denying the server the privilege to read or write
> > anywhere outside
> > /var/lib/pgsql. Check for messages about this in
> > /var/log/messages.
> >
>
> I turned off SELinux, and that seemed to do it.
> Thanks, I would have never thought of that.
>
> The thing is - I had *tried* having the files in
> /var/lib/pgsql (also /var/lib/pgsql/migrate). Maybe
> they have to be in /var/lib/pgsql/data? I'm sure
> ownership/rights were correct.

No, no. It's not how SELinux policies work. They are
completely orthogonal to ownership/permissions.

There is a process called labelling, during which
each and every file is being marked with a label.
A label describes what kind of data such file is,
for instance "config file for Apache" or "database
file for PostgreSQL" (only the labels are symbolic,
not English text).

Then, each process runs in a context, say maybe
a PostgreSQL server context. The context defines
what can it do -- which ports can it bind to, which
files (which labels!) can it read and/or write etc.

If you simply moved files into /var/lib/pgsql/ it probably
wasn't enough -- files probably are already labelled
as your home directory files or so. You need to
relabel them so PostgreSQL could read them
(I don't remember the command to do so).

And please note that when you try using PL/perl you may
run into problems -- the policy definition may not contain
permissions to read perl modules. And so on, and so on.

SELinux is a fine piece of software, but it's a sturdy beast
to configure and I tend to think that the best approach is
to write policy from scratch tailored to specific needs...

Regards,
Dawid