How to enable group-writable suexec-capable CGI scripts?

Question

I have been asked to set up a shared webspace on our department webserver that may be accessed by multiple people and which might be running CGI or PHP scripts. The people maintaining the webspace might decide to use it for file submissions, which would mean that they'd need access to any files created by the scripts. We're running Apache on Scientific Linux 6.

Because multiple people need write access to the webspace, our standard approach is to create a group to which all of the relevant people belong and then set the permissions on the directories in the webspace to g+ws. suexec is unhappy with the files being group-writable and refuses to run them.

How can we set this up and make sure that any scripts are run under an account that is different from the main apache account (and is different from any of the users who are not in the group for the webspace)? For accountability (and other) reasons, I'd prefer not to have to make a shared account that the various people would have to use to maintain this webspace.

For a little more context, here's how we're currently set up: We have users whose home directories are on NFS and automounted as needed. Most people just use their personal webspace accessed via mod_userdir. We've fielded several requests for shared webspace in the past by creating additional automounted directories on the NFS server that are not tied to particular accounts, but which have group ownership set up to facilitate access by multiple accounts. Up to now, these shared spaces have only contained static content (and we've trusted the people involved not to run scripts from them), so we've never had to address any suexec-related issues for these sorts of spaces before.

---

Edit: Note that the users might need access to files created by the scripts.

Answer 1

To ensure accountability in this context and yet provide the correct ownership and permissions for the published content, I use a slightly modified version of the workflow described in this article.

This is how I have implemented, note that most of the pieces are replaceable:

• All the published content is managed by a version control system (git in this case)
• Users have nominal accounts registered in a Kerberized LDAP along with their RSA public keys
• In the past, I used such public keys to grant access to the different repos using gitosis/gitolite, but you can also use plain git with git-shell.
• A while back, I moved to gitblit, which provides LDAP authorization. The access to gitblit's web UI requires a valid kerberos ticket.
• The repos have their post-update hook symlinked to a script containing:

#!/bin/sh

sudo /usr/local/sbin/publisher-hub2live

exit 0

The script is not directly accessible to unauthorized users:

# ls -lrt /usr/local/sbin/publisher-hub2live
-rwx------. 1 root root 400 Oct 12  2012 /usr/local/sbin/publisher-hub2live

Hence the sudorule:

Defaults:git   !requiretty
git   Host_Alias = (root) NOPASSWD: /usr/local/sbin/publisher-hub2live

Replace git with the actual owner of the repositories.

The contents of the publisher script work the "magic" here (simplified version):

#!/bin/sh

echo
echo "**** Pulling changes into Live [Hub's post-update hook]"
echo

cd /path/to/live/repo || exit
umask 0022
unset GIT_DIR
git pull hub master

chown -R root:root /path/to/live/repo
find /path/to/live/repo/ -type d | xargs chmod u=rwx,go+rx
find /path/to/live/repo/ -type f | xargs chmod u=rw,go+r
restorecon -v -R /path/to/live/repo

exec git update-server-info

exit 0

Your needs might differ with regards to the owner, group, DAC and MAC permissions, but the workflow is the same.