Mailing List Archive: FastCGI startup strangeness

FastCGI startup strangeness

Sep 18, 2014, 2:01 PM

Post #1 of 3 (1930 views)

I noticed today that an app I'm working on will start fine only if the user who is running the app can read the current directory (ie, if I'm starting it as a user dedicated to running the app, that user must have read permission on CWD).

Couldn't load class (MYAPP::Script::FastCGI) because: Can't locate MYAPP/Script/FastCGI.pm: Permission denied at /path/to/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 13.
Catalyst::ScriptRunner::find_script_class("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/perl/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 42
Catalyst::ScriptRunner::run("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/MYAPP/script/MYAPP_fastcgi.pl line 4

strace shows the difference between a successful launch and a failed one is whether we get EACCESS or ENOENT when looking for ./MYAPP/Script/FastCGI.pm

failure:
stat("./MYAPP/Script/FastCGI.pmc", 0x7fffa8eba720) = -1 EACCES (Permission denied)
stat("./MYAPP/Script/FastCGI.pm", 0x7fffa8eba660) = -1 EACCES (Permission denied)

success:
stat("./MYAPP/Script/FastCGI.pmc", 0x7fff80e76db0) = -1 ENOENT (No such file or directory)
stat("./MYAPP/Script/FastCGI.pm", 0x7fff80e76cf0) = -1 ENOENT (No such file or directory)

I didn't see this documented anywhere - am I missing some obvious reason why this behavior is desired?
--
Daniel J. Luke
+========================================================+
| *---------------- dluke@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: FastCGI startup strangeness [ In reply to ]

ilmari at ilmari

Sep 18, 2014, 2:21 PM

Post #2 of 3 (1880 views)

Permalink

"Daniel J. Luke" <dluke@geeklair.net> writes:

> I noticed today that an app I'm working on will start fine only if the
> user who is running the app can read the current directory (ie, if I'm
> starting it as a user dedicated to running the app, that user must
> have read permission on CWD).
>
> Couldn't load class (MYAPP::Script::FastCGI) because: Can't locate MYAPP/Script/FastCGI.pm: Permission denied at /path/to/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 13.
> Catalyst::ScriptRunner::find_script_class("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/perl/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 42
> Catalyst::ScriptRunner::run("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/MYAPP/script/MYAPP_fastcgi.pl line 4
>
> strace shows the difference between a successful launch and a failed
> one is whether we get EACCESS or ENOENT when looking for
> ./MYAPP/Script/FastCGI.pm

This is due to require as of 5.18 no longer silently ignoring errors
when trying to load a module:

require dies for unreadable files

When require encounters an unreadable file, it now dies. It used
to ignore the file and continue searching the directories in @INC
[perl #113422].

https://metacpan.org/pod/perl5180delta#require-dies-for-unreadable-files

Combined with the fact that Catalyst::ScriptRunner tries to load the
optional (but in your case non-existent) MYAPP::Script::FastCGI, and
that '.' is in @INC by the default, it gives this (somewhat annoying)
behaviour.

For daemons it is generally a good idea to cd to / or some
application-specific directory before starting up, to avoid e.g. it
accidentally hanging onto a mount point.

> failure:
> stat("./MYAPP/Script/FastCGI.pmc", 0x7fffa8eba720) = -1 EACCES (Permission denied)
> stat("./MYAPP/Script/FastCGI.pm", 0x7fffa8eba660) = -1 EACCES (Permission denied)
>
> success:
> stat("./MYAPP/Script/FastCGI.pmc", 0x7fff80e76db0) = -1 ENOENT (No such file or directory)
> stat("./MYAPP/Script/FastCGI.pm", 0x7fff80e76cf0) = -1 ENOENT (No such file or directory)
>
> I didn't see this documented anywhere - am I missing some obvious reason why this behavior is desired?

--
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's good to know where it is, but you generally
don't want to find yourself in the same spot." - Tollef Fog Heen

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: FastCGI startup strangeness [ In reply to ]

dluke at geeklair

Sep 19, 2014, 1:10 PM

Post #3 of 3 (1883 views)

Permalink

On Sep 18, 2014, at 5:21 PM, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> wrote:
>
> "Daniel J. Luke" <dluke@geeklair.net> writes:
>
>> I noticed today that an app I'm working on will start fine only if the
>> user who is running the app can read the current directory (ie, if I'm
>> starting it as a user dedicated to running the app, that user must
>> have read permission on CWD).
>>
>> Couldn't load class (MYAPP::Script::FastCGI) because: Can't locate MYAPP/Script/FastCGI.pm: Permission denied at /path/to/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 13.
>> Catalyst::ScriptRunner::find_script_class("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/perl/perl-5.20.0/lib/site_perl/5.20.0/Catalyst/ScriptRunner.pm line 42
>> Catalyst::ScriptRunner::run("Catalyst::ScriptRunner", "MYAPP", "FastCGI") called at /path/to/MYAPP/script/MYAPP_fastcgi.pl line 4
>>
>> strace shows the difference between a successful launch and a failed
>> one is whether we get EACCESS or ENOENT when looking for
>> ./MYAPP/Script/FastCGI.pm
>
> This is due to require as of 5.18 no longer silently ignoring errors
> when trying to load a module:
>
> require dies for unreadable files
>
> When require encounters an unreadable file, it now dies. It used
> to ignore the file and continue searching the directories in @INC
> [perl #113422].
>
> https://metacpan.org/pod/perl5180delta#require-dies-for-unreadable-files
>
> Combined with the fact that Catalyst::ScriptRunner tries to load the
> optional (but in your case non-existent) MYAPP::Script::FastCGI, and
> that '.' is in @INC by the default, it gives this (somewhat annoying)
> behaviour.

would it be worthwhile for Catalyst::ScriptRunner to check if the file exists before trying to load it?

> For daemons it is generally a good idea to cd to / or some
> application-specific directory before starting up, to avoid e.g. it
> accidentally hanging onto a mount point.

true, and for the 'general' case, I don't hit this issue. I noticed it in my DEV instance where I was in my $HOME and trying to run the app as the 'normal' app user by hand instead of with the startup scripts we normally use.

>> failure:
>> stat("./MYAPP/Script/FastCGI.pmc", 0x7fffa8eba720) = -1 EACCES (Permission denied)
>> stat("./MYAPP/Script/FastCGI.pm", 0x7fffa8eba660) = -1 EACCES (Permission denied)
>>
>> success:
>> stat("./MYAPP/Script/FastCGI.pmc", 0x7fff80e76db0) = -1 ENOENT (No such file or directory)
>> stat("./MYAPP/Script/FastCGI.pm", 0x7fff80e76cf0) = -1 ENOENT (No such file or directory)
>>
>> I didn't see this documented anywhere - am I missing some obvious reason why this behavior is desired?

--
Daniel J. Luke
+========================================================+
| *---------------- dluke@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+

_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/