[SOLVED] Implications of making users members of 'apache' group

Wim Sturkenboom · 06-02-2009, 01:17 AM

Currently I'm the developer, maintainer, admin etc on a LAMP server with a few websites on an intranet.

The responsibilities need to be split so we'll have a root user, a sysadmin user (can remotely login and su to root), a MySQLadmin user and one or more (maintenance) users for the websites.

The websites usually contain a subdirectory 'files' where apache needs to be able to write files.
I always run into the issue that I have to chmod the 'files' directory to apache which can not be done by the maintenance user as he/she is not a member of the apache group. Also restoring a backup (from a tarball) causes problems as the 'files' directory now belongs to the primary group of the maintenance user.

Therefore I have been thinking to make 'apache' the primary group of the maintenance users.

I however can not oversee the security implications. Is it advisable or is there a better way?

Can somebody please advice about these implications?

Code:

/home
  +-- website1
  |      +---- www (document root)
  |      |      +--- files (need to be writable by apache)
  |      +---- inc
  +-- website2
  |      +---- www
  |      |      +--- files
  |      +---- inc

Thanks in advance, WimS

unSpawn · 06-02-2009, 12:45 PM

How about Sudo? Or ACL (http://acl.bestbits.at/)?

Wim Sturkenboom · 06-03-2009, 01:51 AM

I'm not sure how sudo can help in this case. Maybe somebody can explain that and give an example.

So I opted for ACLs. Here's the story (possibly as a reference for others):

After some reading of the man pages, the first attempt

Code:

setfacl -m u:apache:rwx files

This failed with a 'operation not permitted' message although the --test option did not give an error.

Read again and fixed it by changing the default mounting options of the file system

Code:

tune2fs -o acl /dev/cciss/c0d0p1

Try again, same message.

Think, think again and suspect that the mount option might only take affect at mount time so rebooted the system (an unmount / mount probably would have done the trick).

Ran the setfacl again

Code:

setfacl -m u:apache:rwx files
no errors
getfacl files
# file: files
# owner: wim
# group: wim
user::rwx
user:apache:rwx
group::r-x
mask::rwx
other::r-x

To test, I temporary allowed the apache user to login, su'd to apache and attempted to create a file in the files directory. And YES, it works.

Thanks unSpawn

PS
to make the post complete:

Slackware 12.0
ext3 filesystems (not every filesystem might support ACLs or one might need a different command to set the default mounting options)

unSpawn · 06-03-2009, 02:30 AM

Sudo was only offered as a means to enable other roles to chown files where ACL isn't available. Good to see ACLs work for you and thanks for the elaborate response.