пользователя на сайте Apache2 (Debian)

Списки управления доступом к файлам могут оказаться полезными, так как каждый пользователь может владеть своими собственными файлами, но вы можете использовать списки управления доступом, чтобы позволить apache читать их. Вы также можете посмотреть разрешения по умолчанию с помощью ACL.

Модуль ITK для apache2 обеспечивает поддержку разных системных пользователей для каждого виртуального хоста. Он упакован для Debian как apache2-mpm-itk.

Он не создает и не управляет пользователями -, которые зависят от вас, с помощью обычных инструментов.

Раньше я часто использовал это (, когда запускал множество виртуальных хостов на общем сервере ), и обычно я устанавливал его так, чтобы каждый виртуальный хост имел свой собственный домашний каталог (/home/WEB/username), с html, logs, cgi-binи все остальное, связанное с этим виртуальным хостом в их домашнем каталоге. Это упростило миграцию на другой сервер при необходимости.

Владельцу виртуального хоста также стало проще использовать ftpили sftpдля обновления своего сайта или извлечения собственных файлов журналов и т. д. Кроме того, владелец одного виртуального хоста не мог читать принадлежащие ему файлы. другим виртуальным хостам -, защищая конфиденциальную информацию, такую ​​как пароли баз данных, встроенные в скрипты или файлы конфигурации.

С веб-страницы ITK:

apache2-mpm-itk (just mpm-itk for short) is an MPM (Multi-Processing Module) for the Apache web server. mpm-itk allows you to run each of your vhost under a separate uid and gid—in short, the scripts and configuration files for one vhost no longer have to be readable for all the other vhosts.

mpm-itk is based on the traditional prefork MPM, which means it's non-threaded; in short, this means you can run non-thread-aware code (like many PHP extensions) without problems. On the other hand, you lose out to any performance benefit you'd get with threads, of course; you'd have to decide for yourself if that's worth it or not. You will also take an additional performance hit over prefork, since there's an extra fork per request.

и:

The new configuration settings over the prefork MPM are:

• AssignUserID: Takes two parameters, uid and gid (or really, user name and group name; use “#” if you want to specify a raw uid); specifies what uid and gid the vhost will run as (after parsing the request etc., of course). Note that if you do not assign a user ID, the default one from Apache will be used.

• AssignUserIDExpr, AssignGroupIDExpr (Apache 2.4 or newer only): Like AssignUserID, but takes in an Apache expression to dynamically choose user or group. See below.

• MaxClientsVHost: A separate MaxClients for the vhost. This can be useful if, say, half of your vhosts depend on some NFS server; if the NFS server goes down, you do not want the children waiting forever on NFS to take the non-NFS-dependent hosts down. This can thus act as a safety measure, giving “server too busy” on the NFS-dependent vhosts while keeping the other ones happily running. (Of course, you could use it to simply keep one site from eating way too much resources, but there are probably better ways of doing that.)

• NiceValue: Lets you nice some requests down, to give them less CPU time.

• EnableCapabilities (Apache 2.4 or newer only): Drop most root capabilities in the parent process, and instead run as the user given by the User/Group directives with some extra capabilities (in particular setuid). Somewhat more secure (especially when coupled with LimitUIDRange above), but can cause problems when serving from filesystems that do not honor capabilities, such as NFS.

• LimitUIDRange, LimitGIDRange (Apache 2.4 or newer only): Restrict setuid() and setgid() calls to a given range (e.g. “LimitUIDRange 1000 2000" to allow only uids from 1000 to 2000, inclusive), possibly increasing security somewhat. Note that this requires seccomp v2 (Linux 3.5.0 or newer). Also, due to technical reasons, setgroups() is not restricted, so a rogue process can still get any group it might want. Still, performing a successful attack will be somewhat trickier than otherwise.