new paste || ipv4:js fail, n/a or broken? | ipv6:js fail, n/a or broken? ||

paste 10735/b28a | 3371 views since 2015-08-19 09:35:20 | text/plain | wrap || empty reply | copy reply | quote reply 
js:(
Gotcha, well I've traced the error to a call to ap_run_open_htaccess inside
apache itself.  getuid() returns 33 (www-data) right before this call, on
the local filesystem this call returns APR_ENOTDIR and on the remote
filesystem it returns APR_EACCES.  The document root directory has 700
permissions and is owned by uid 43959 in both cases so I'm not sure how uid
33 would be able to access it locally.  I'm guessing something else is
going on but this was as far as I was able to trace it, I can't find the
definition for ap_run_open_htaccess() anywhere in the source

paste 10736/c71b | 3786 views since 2015-08-19 09:35:43 | text/plain | wrap || empty reply | copy reply | quote reply 
js:(
> getuid() returns 33 (www-data) right before this call, on
> the local filesystem this call returns APR_ENOTDIR and on the remote
> filesystem it returns APR_EACCES.  The document root directory has 700
> permissions and is owned by uid 43959 in both cases so I'm not sure how uid
> 33 would be able to access it locally.

Again, it has extra capabilities that getuid wouldn't pick up.
In particular, CAP_DAC_READ_SEARCH. I don't know if these would work well
over NFS or not, but from what you're saying, probably not.

> I'm guessing something else is
> going on but this was as far as I was able to trace it, I can't find the
> definition for ap_run_open_htaccess() anywhere in the source

It's in Apache since 2.4.7, if I recall correctly.