unreturned

zzzit, с этого ракурса (когда все пользователи в системе, даже системные, враги) - полностью согласен. Однако в таком случае на критичные данные (конфиги и прочее) должны стоять права (rwx)?00.

Да нету никаких проблем, либо у нас с Вами непонимание, либо ... 🤪

Привожу пример:

root@server0:~# ls -alR /home/

/home/:

итого 16

drwxr-xr-x  4 root  root  4096 дек  7 18:30 .

drwxr-xr-x 23 root  root  4096 дек  7 18:22 ..

drwx-----x  2 user1 users 4096 дек  7 18:33 user1

drwx-----x  2 user2 users 4096 дек  7 18:34 user2



/home/user1:

итого 28

drwx-----x 2 user1 users 4096 дек  7 18:33 .

drwxr-xr-x 4 root  root  4096 дек  7 18:30 ..

-rw------- 1 user1 user1   29 дек  7 18:33 .bash_history

-rw-r--r-- 1 user1 user1  220 дек  7 18:29 .bash_logout

-rw-r--r-- 1 user1 user1 3515 дек  7 18:29 .bashrc

-rw-r--r-- 1 user1 user1  675 дек  7 18:29 .profile

-rw-r--r-- 1 user1 user1   10 дек  7 18:33 testfile1



/home/user2:

итого 28

drwx-----x 2 user2 users 4096 дек  7 18:34 .

drwxr-xr-x 4 root  root  4096 дек  7 18:30 ..

-rw------- 1 user2 user2   55 дек  7 18:34 .bash_history

-rw-r--r-- 1 user2 user2  220 дек  7 18:30 .bash_logout

-rw-r--r-- 1 user2 user2 3515 дек  7 18:30 .bashrc

-rw-r--r-- 1 user2 user2  675 дек  7 18:30 .profile

-rw-r--r-- 1 user2 user2   10 дек  7 18:34 testfile2

root@server0:~# sudo -u user2 -i

user2@server0:~$ cat /home/user1/testfile1

cat: /home/user1/testfile1: Отказано в доступе

user2@server0:~$ logout

root@server0:~# sudo -u user1 -i

user1@server0:~$ cat /home/user2/testfile2

cat: /home/user2/testfile2: Отказано в доступе

user1@server0:~$ logout

root@server0:~# sudo -u www-data -s

www-data@server0:/root$ cat /home/user1/testfile1

testfile1

www-data@server0:/root$ cat /home/user2/testfile2

testfile2

www-data@server0:/root$ 

Как видно, пользователи к друг другу доступа никакого не имеют, а веб-сервер успешно сможет отдавать данные пользователей.

Ну если на все выше стоящие каталоги также будет разрешено всем ходить, то да, в таком варианте Ваше утверждение будет справедливо.

А так стандартная схема простая, есть пользователи, которые добавлены в группу users и домашний каталог пользователя имеет права 701

sudo ls -all /home/

total 12

drwxr-xr-x  3 root    root    4096 марта 13  2015 .

drwxr-xr-x 23 root    root    4096 дек.   6 23:46 ..

drwx-----x 30 support users 4096 дек.   8 00:04 support

drwx-----x 30 user1 users 4096 дек.   8 00:04 user1

И все, никаких проблем.

У меня последняя цифра на файлы 4 (чтение), а на директории 5 (чтение + выполнение, т.е. переход). Веб-сервер nginx у меня работает от своего пользователя nginx, а php-fpm пулы работают от пользователей. В чем у меня проблема?

Нет, суть в другом. Судя по владельцам файлов, ТС похакали через http://www.opennet.ru/opennews/art.shtml?num=42015

Не видел ни одной CMS, которой бы действительно были нужны права 777.

Права 777 обычно ставятся только от полной безграмотности и неумения настраивать веб-сервер.

Да, в Ubuntu 12.04 / 14.04 проблему с mod_copy до сих пор не починили http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3306.html

Лечение:

sed -i 's|LoadModule mod_copy.c|#LoadModule mod_copy.c|g' /etc/proftpd/modules.conf

service proftpd restart

Однако если proftpd смог записать Вам что-то в директории сайтов, значит у Вас стоят крайне не безопасные права 777. Избавляйтесь от них.

Так этож https://vestacp.com/

Попробуйте ознакомиться со статьей https://www.nginx.com/blog/9-tips-for-improving-wordpress-performance-with-nginx/

twiprogon:
с днс-ами от гугла, тьфу тьфу вроде пока норм все.
Хочу поставить htop на сервер но пакеты установочные не доступны, 404 ошибка
Как быть, подскажите?

Сначала попробуйте выполнить apt-get update, как и указано.

http://www.linuxatemyram.com/