2

I'm porting a Windows perl/postgresql web app to CentOS.

In postgresql.conf I have these lines:

custom_variable_classes = 'plperl'              # list of custom variable class names

plperl.use_strict = on

plperl.on_plperlu_init = 'require "/path/to/my/app/dev/area/MyModule.pm";'

In Windows 2003, this allowed me to put use MyModule; in plperlu functions in PostgreSQL, and they would work, provided I had gone to the path with the .pm files and changed the ACLs to give user postgres "Read" and "Read & Execute" permissions in the Security tab.

On CentOS 6.4, I'm a bit confused. When I try to define a plperlu function calling MyModule, it gives me ERROR: Can't locate /path/to/my/app/dev/area/MyModule.pm in @INC.

I'm confused because MyModule.pm is owned by me:me, and had 664 perms. I tried 665 and still no luck: sudo -u postgres ls -l /path/to/my/app/dev/area/MyModule.pm reports Permission denied. As far as I thought I understood unix permissions, 665 means that 'other' has permission to read and execute.

Kev
  • 15,899
  • 15
  • 79
  • 112

1 Answers1

0

I just wrote this up and realized I had recently learned the answer.

Unlike our Windows setup, Linux needs permissions from all directories along the path. So I started doing ls -l on the path, and shorter and shorter. It was 644 all the way up until near the top, where I had a 700. I did chmod 705 (also chmod 701 worked, I switched to that after) on that, and bingo, sudo -u postgres ls could see it, and so could my plperlu function definition.

Kev
  • 15,899
  • 15
  • 79
  • 112
  • 1
    Actually, Perl just needs execute access, not read access. For directories, read access lets you get a directory listing, and execute access lets you access files by name. Since Perl is looking for a specific filename, it doesn't need to get a directory listing. So `chmod 701` would have worked, too. – cjm Sep 27 '13 at 20:49