Re: Solaris 10u9, PG 8.4.6, 'c' lang function, fails on 1 of 5 servers - Mailing list pgsql-general

From dennis jenkins
Subject Re: Solaris 10u9, PG 8.4.6, 'c' lang function, fails on 1 of 5 servers
Date
Msg-id CAAEzAp_SCoOv+g_g5nMqfrkLAA4xt1Lj9buunwjWb+yo-+auww@mail.gmail.com
Whole thread Raw
In response to Solaris 10u9, PG 8.4.6, 'c' lang function, fails on 1 of 5 servers  (dennis jenkins <dennis.jenkins.75@gmail.com>)
List pgsql-general

On Thu, Sep 29, 2011 at 12:08 PM, dennis jenkins <dennis.jenkins.75@gmail.com> wrote:

(root@failed: </db>) #  psql -Upgsql -dmy_db -c"create or replace function parse_micr(text) returns micr_struct
 as '/db/pgsql_micr_parser_64.so', 'pgsql_micr_parser' language c volatile cost 1;"
ERROR:  could not load library "/db/pgsql_micr_parser_64.so": ld.so.1: postgres: fatal: /db/pgsql_micr_parser_64.so: Permission denied

stat("/db/pgsql_micr_parser_64.so", 0xFFFFFD7FFFDF8F50) = 0
resolvepath("/db/pgsql_micr_parser_64.so", "/db/pgsql_micr_parser_64.so", 1023) = 27
open("/db/pgsql_micr_parser_64.so", O_RDONLY)   = 22
mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 22, 0) Err#13 EACCES
close(22)                                       = 0


Problem solved.

First, some more background.  These 5 postgresql servers are local zones running in Solaris. (like a "linux container").  The database itself is inside "/db".  The database user ("pgsql") has no problems reading any file there, including the micr_parser.so file.

"/db" is not just a directory under "/".  It is a separate file system mounted within the zone (via a loopback mount).  The actual file-system is a ZFS sub-filesystem on a dedicated zpool on the (shared) servers.  On the four servers where the "create function" worked, "/db" was mounted with options "nodevices".

However, on the server where it failed, "/db" was mounted with "nodevices,noexec".  This was causing mmap() to fail when it requested "PROT_EXEC" access.

My inspiration for solving this riddle was that I copied the .so to a local directory under "/" that was not under "/db".  "create function" then succeeded.  The little light bulb over my head turned on and I began checking filesystem mount flags.

So, for anyone who finds this posting via a search engine years from now... if "create function" fails with "permission denied", also check that the filesystem holding the ".so" file is not mounted with "exec" disabled.

I've not tested this behavior on Linux.  I humble suggest putting a note in the postgresql documentation about the FS mount flags impact on 'C' language functions.

pgsql-general by date:

Previous
From: Cédric Villemain
Date:
Subject: Re: Never-idle autovacuum, and does (auto)vacuuming fill the OS cache ?
Next
From: Joe Conway
Date:
Subject: Call For Talks: PGDay.SoCal @ SCALE 10X