没有CHMOD 777,无法在NGINX中创建文本文件或将其追加到文本文件中 [英] Can't create text file or append to it in NGINX without CHMOD 777
问题描述
使用Lightsail NGINX实例,并在PHP文件中获得一行内容,这行将无法满足我的需要
$s = 'Hello world';
$myfile = file_put_contents('log.txt', $s.PHP_EOL , FILE_APPEND | LOCK_EX);
如果不存在,我希望它创建log.txt文件.如果有,我要附加它.它也不做.
如果我创建文件,它将无法正常工作.仅当我通过SSH将文件更改为777时,它才能工作.
但是,将来要做的工作是制作文件,因此出于777安全性之外的原因,这种手动方法将不可行.
我知道这取决于安全性设置,但实际上不确定如何做才能确保此安全性,同时仍然允许PHP访问创建/附加到文本文件
看来我有一个叫www-data的用户.我已经尝试过:
sudo chown -R www-data:www-data html
sudo chmod -R g+s html
仍然无法创建文件.
如果我报告错误,我会得到:
file_put_contents(log.txt): failed to open stream: Permission denied
谢谢
我真的很想知道人们在完全缺乏OP服务器设置细节的情况下如何建议chmod
或chown
.
根据目前为止提到的所有内容,我可以假设:OP的运行方式是这样的:
- 以
www-data
身份运行的NGINX. - PHP-FPM以不同的用户名运行(因此出现权限问题).假设PHP-FPM池的用户名是
foo
.
让我们概述这种设置的最佳实践.这样一来,您将很快获得良好的状态,而不会遇到权限问题.
谁必须拥有文件
通常(无论是否有多站点服务器),都需要一个拥有站点文件的特定用户.该用户应该从不为www-data
.为此,它必须是您创建的单独用户:foo
.
通常,同一用户foo
将被设置为与之一起运行PHP-FPM池.
因此,为foo
用户设置正确的所有权:
chown -R foo:foo /path/to/your/site/html
由于PHP-FPM脚本以foo
身份运行,因此目录和其中的所有文件均由同一foo
拥有,因此PHP-FPM可以在那里毫无问题地完成工作.这样,您将绝对不会有PHP无法创建/访问内容的可能性.
授予对Web服务器的访问权限
请记住,该设置涉及两个用户:一个是Web服务器(www-data
),一个是PHP-FPM(foo
).
现在文件已由foo
正确拥有,我们需要将 read 的权限授予www-data
.为什么只看书?因为NGINX与在此设置中写入文件系统无关.它只需要读取文件并遍历目录.
通常是通过使Web服务器的用户成为站点用户组的成员来完成此授予的.一开始很难理解,但是我会更加冗长:
假设有一个站点文件data.txt
,该站点文件现在由foo:foo
拥有-Linux中的所有权是双重所有权:该文件由foo
用户和foo
组拥有.
现在foo
组只有一个成员:foo
用户.
我们需要做的是将另一个成员添加到foo
组:www-data
用户.
因此:
usermod -a -G foo www-data
此后,foo
组具有以下成员:foo
用户,www-data
用户.
现在我们可以继续使用权限了:)
应该具有什么权限
现在我们已经完成了所有权,剩下的重要一点是通过这种方式调整所有文件和目录的权限:
- 目录应允许对组进行遍历(
+x
) - 文件应允许读取(
+r
)用于组
这些权限是www-data
能够读取每个网站文件和目录所必需的.
您很有可能不需要显式设置这些设置,因为umask
设置(在这里我将不涉及此主题)将已经使所有文件都具有这些权限.
但是,如果您需要修复自己的东西,可以这样做:
chmod -R g+rX /path/to/your/site/html
大写的X
确保仅为目录设置+x
.
确保安全
在为这种设置设置了正确的文件和组所有权之后,您可以进一步提高安全性并设置更具限制性的chmod
.
例如, Magento安全chmod 遵循该设置约定,因此可以对PHP文件具有0400
的chmod
权限,对于媒体文件具有0640
的0640
权限:)
除非您要处理的是真正奇怪的用例,否则最后一个chmod
位应始终为0.
Using Lightsail NGINX instance and got a one line in a PHP file that won't do what I need
$s = 'Hello world';
$myfile = file_put_contents('log.txt', $s.PHP_EOL , FILE_APPEND | LOCK_EX);
I want it to create the log.txt file if it's not there. If it is there, I want it to append. It does not do either.
If I create the file, it doesn't work. Only if I chmod the file to 777 via SSH will it work.
However a future piece of work would be to make the file so for reasons beyond the security of 777, this manual approach won't be feasible.
I understand this is down to security settings but really unsure on what to do to make this as secure as I can whilst still giving the PHP access to create/append to a text file
It appears I have a user called www-data. I have tried:
sudo chown -R www-data:www-data html
sudo chmod -R g+s html
Still can't create the file.
If I put error reporting on I get:
file_put_contents(log.txt): failed to open stream: Permission denied
Thanks
I'm really wondering how people advise on doing chmod
or chown
while completely lacking details of OP's server setup.
Based on everything mentioned so far, I can assume that the OP has things running this way:
- NGINX running as
www-data
. - PHP-FPM running as different username (thus the permission issue). Let's say the PHP-FPM pool's username is
foo
.
Let's outline the best practices for this kind of setup. Following that, you'll be good with no permissions issues, in no time.
Who must own the files
Usually (multi-site server or not), you want one specific user who owns the site files. That user should never be www-data
. It must be a separate user that you have created for this purpose: foo
.
As a rule, that same user foo
will be the one who is set to run PHP-FPM pool with.
So set the correct ownership to the foo
user:
chown -R foo:foo /path/to/your/site/html
Since PHP-FPM scripts run as foo
, now that the directory and all the files inside it are owned by that very same foo
, the PHP-FPM can do its stuff there without any problem. In that way, you will absolutely never have even the possibility that PHP cannot create / access stuff.
Grant access to web server
Remember, there are two users involved in the setup: one is web server's (www-data
) and one is PHP-FPM's (foo
).
Now that the files are properly owned by foo
, we need to grant the rights to read them to www-data
. Why only read? Because NGINX has nothing to do with writing to the filesystem in this setup. It only needs to read files and traverse directories.
How this granting is usually accomplished is by making web server's user to be a member of the site user's group. This is a bit hard to comprehend at first, but I'll be further verbose about it:
Let's say there is a site file data.txt
, that is now owned by foo:foo
- the ownership in Linux is double-fold: file is owned by foo
user and foo
group.
Right now the foo
group has only one member: foo
user.
What we need to do is to add another member to the foo
group: the www-data
user.
Thus:
usermod -a -G foo www-data
After this, the foo
group has these members: foo
user, www-data
user.
And now we can continue onto permissions :)
What permissions should be
Now that we're done with ownership, the remaining important bit is to adjust permissions for all files and directories in this way:
- directories should allow for traversing (
+x
) for group - files should allow being read (
+r
) for group
These permissions are required for www-data
to be able to read every website file and directory.
Most likely, you don't need to explicitly set those, because umask
setting (I will not touch upon this topic here), will be already such that all files already have these permissions.
But if you need to fix your stuff, you can do:
chmod -R g+rX /path/to/your/site/html
The uppercase X
ensures that +x
is set for directories only.
Going secure
After setting up the right file and group ownership for this kind of setup, you can go further secure and set more restrictive chmod
.
For example, Magento secure chmod follows that setup's conventions so you can be fine with chmod
permissions of 0400
for PHP files and 0640
for media files :)
The last chmod
bit should always be 0 unless you're dealing with a truly odd use case.
这篇关于没有CHMOD 777,无法在NGINX中创建文本文件或将其追加到文本文件中的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!