Debian服务器下授权Admin站点操作Public站点文件的最优方案

Alright, let's break down the secure, functional setup for your scenario—we need the Admin site's PHP processes to modify the Public site on Debian, while balancing access control and security to avoid over-permissive risks. Here's a step-by-step approach:

1. Create a Shared User Group #

We’ll use a dedicated group to bridge the two site users and the PHP execution context, so they can collaborate on the Public directory without full unrestricted ownership.

• Create a group for web content management:

  sudo groupadd web_content_group
  

• Add all relevant users to this group (replace www-data with your custom PHP-FPM/Apache user if you’ve modified it):

  sudo usermod -aG web_content_group admin_user
  sudo usermod -aG web_content_group public_user
  sudo usermod -aG web_content_group www-data
  

  Note: If your Admin site uses a custom PHP-FPM pool running exclusively as admin_user, you can skip adding www-data—just ensure the pool’s user is part of the shared group.

2. Configure Public Directory Ownership & Permissions #

Set up the Public directory to remain owned by public_user, but grant controlled write access to the shared group, with inheritance for new files/directories.

• Set the base ownership:

  sudo chown -R public_user:web_content_group /var/www/public
  

• Apply setgid permission to directories (this ensures new files/folders inherit the shared group instead of the creator’s primary group):

  sudo find /var/www/public -type d -exec chmod 2775 {} \;
  

• Restrict file permissions to allow group read/write, while locking out untrusted users:

  sudo find /var/www/public -type f -exec chmod 664 {} \;
  

3. Tune PHP for Safe Cross-Directory Access #

Ensure your Admin site’s PHP environment is allowed to interact with the Public directory without violating security guardrails:

• Check open_basedir in your PHP config (either php.ini or your PHP-FPM pool config):
  • If enabled, add /var/www/public to the allowed paths, e.g.:

    open_basedir = /var/www/admin/:/var/www/public/:/tmp/
    

• Verify mkdir() and copy() are not listed in disable_functions—these need to be available for your use case.
• If using PHP-FPM, confirm your Admin pool’s user and group align with the shared group setup:

  user = admin_user
  group = web_content_group
  

4. Optional: Fine-Grained Access with ACLs #

If you don’t want the entire Public directory writable by the Admin site, use Access Control Lists (ACLs) to restrict write access to specific subdirectories (e.g., an uploads folder):

• Grant recursive read/write access to admin_user for a target subdirectory:

  sudo setfacl -R -m u:admin_user:rwx /var/www/public/uploads
  

• Set default ACLs so new files/folders in that subdirectory inherit the permissions automatically:

  sudo setfacl -R -d -m u:admin_user:rwx /var/www/public/uploads
  

Critical Security Reminders #

• Never use 777 permissions: This gives every user on the server full access, which is a catastrophic security risk.
• Lock down the Admin site: Use IP whitelisting, HTTP Basic Auth, or a secure login system to ensure only trusted users can trigger the PHP mkdir()/copy() functions.
• Audit permissions regularly: Periodically run ls -l /var/www/public and getfacl /var/www/public to verify permissions haven’t been altered unexpectedly.

内容的提问来源于stack exchange，提问作者jotyhista