文件系统权限导致基于 cURL 的缓存脚本中断
我正在用 PHP 编写这个 cURL 脚本。它的目的是获取给定的产品或类别代码(此时它是哪种类型的代码是不明确的,当然,类别和产品可能具有相同的代码,但这就是业务规则的用途,并且这个问题与什么无关),然后尝试使用它加载我们的购物车上的产品或类别页面。无论哪个页面返回 200 响应,都会将其输出缓存到 DocumentRoot 中的 html 文件中。
问题是,DocumentRoot 不属于 apache,而且我不愿意向 DocumentRoot 授予全局写入权限,因此虽然脚本在大部分情况下都有效,但页面不会被缓存。
我没有服务器的 root 或 su 访问权限,也无法获得。我尝试将文件写入 /tmp/ 目录,然后移动它,但权限不允许我这样做。有没有办法在不打开安全漏洞的情况下解决这个问题?如果没有,这可以通过 Perl CGI 脚本实现吗?还是我会面临同样的问题?
I'm writing this cURL script in PHP. It's purpose is to take a product or category code given to it (which type of code it is is ambiguous at that point, sure, it's possible for a category and a product to have the same code, but that's what business rules are for and what this question is NOT about), and then attempt to load either a product or category page on our shopping cart with it. Whichever page returns a 200 response then gets its output cached into an html file in the DocumentRoot.
Problem is, the DocumentRoot isn't owned by apache and I don't feel comfortable giving global write permissions to the DocumentRoot, so while the script works for the most part, the page doesn't get cached.
I do not have root or su access to the server and cannot get either. I tried writing the file to the /tmp/ directory and then moving it, but the permissions won't let me. Is there a way around this without opening up a security hole? If not, would this be possible with a Perl CGI script or would I face the same problem?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果 apache 没有执行某些操作的权限,那么除了放入 suid 程序来强制设置权限、使用 suphp 执行相同操作或仅授予所需权限之外,您无法绕过它。
另一种选择是授予 Apache 在文档根目录之外的子目录中的写入权限,然后使用一些 mod_rewrite 魔法来透明地重写对这些缓存文件的请求以使用该子目录。这样你就有了一个可写目录,但不存在使父文档根目录可写的问题。
If apache doesn't have the rights do something, then there's nothing you can do to bypass it short of putting in an suid program to force a permissions set, use suphp to do the same, or just grant the required permissions.
Another option is to grant Apache write permissions in a SUBdirectory off the documentroot, and then use some mod_rewrite magic to make requests for those cached files get transparently rewritten to use the subdir instead. that way you've got a writeable directory, but don't have the issues of making the parent document root writeable.