LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Implications of making users members of 'apache' group (http://www.linuxquestions.org/questions/linux-security-4/implications-of-making-users-members-of-apache-group-730046/)

Wim Sturkenboom 06-02-2009 02:17 AM

Implications of making users members of 'apache' group
 
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 01:45 PM

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

Wim Sturkenboom 06-03-2009 02: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 03: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.


All times are GMT -5. The time now is 04:45 AM.