How to handle user permission issue?

Question

We have created an asset management application web app using php. This app allows users to browse, upload, rename, replace assets (binary files like images and 3d models)

We developed in windows environment and every thing works fine but when we hosted in linux server (joyent) we are running with permission issues in some scenarios. Below is environment setup

Our public web root folder is located in home/jill/web/public (webroot) . All assets are located under home/jill/web/public/assets (assets root) and in sub folders as well

Below are the use cases the way we handling the asset management -

1. Bulk upload all assets using ftp program with ftp user (ftpuser)
2. Bulk upload all assets using webadmin user (jill), who is owner of home/jill/web/public
3. Upload assets using the web app (default web user is www)

In all above use cases, we also overwrite assets with latest modified files. Now there is a flash application (game) hosted in the webroot which access all those assets and loads in the app.

Now we get permission errors when we try to overwrite/update file using a user id different from which is originally created by a different user.

Example: Try to overwrite a file using web app which was initially uploaded using ftp user and vice-verse

What is the way we can handle this scenario so any file or directory created under webroot\assets by any user can be modified by any user ?

I am a developer not familiar with unix/linux but I think it is something to do with handling groups and group permission but I am not sure how to set ?

Answer 1

Try the following. (This has been tested on Lubuntu)

Go to home/jill/web/public and do: ls -la

It will show you the details of the files and folders there. One of them will be assets (this is just an example, your assets details will be different):

-rw-r----- 1 user group 9275204 Jun 13 15:27 assets

The idea is to create a new group and make it the owner of assets and then add all the users to that group.

Create a new group on the server.

groupadd assetgroup

Add the users to the new group:

usermod -a -G assetgroup ftpuser
usermod -a -G assetgroup jill
usermod -a -G assetgroup www

And change the ownership of the assets folder to the assetgroup. (-R is for recursive change)

sudo chgrp -R assetgroup assets/

Answer 2

There are basically two things to this:

1) permissions on the files and directory that already exist:

Alan's answer mostly covers this: create a special group to which you add all users that might need to write the files. Make sure that the directory where you are uploading is itself writable for that group: chmod 0775 path/to/the/directory. Any existing files will need chmod 0664.

The "magic" numbers are octal and stand for triplets: setuid, owner permissions, group permissions, world permissions. The setuid is no of interest for you, keep it 0. for the others the octal number (0-7) tells you the permissions: if the 0th bit is on, the file/directory is executable (for directory it means it can be entered), if 1st bit is on it is writeable, the 2nd bit is managing readability - e.g. 0754 would mean that owner has all permissions, group members can read and execute, and the rest of the world may only read it. You can write the same with mnemonics like this: chmod u=rwx,g=rx,o=r. See man chmod a Linux system for in depth explanation.

2) permissions on newly created files:

Look for umask setting in whatever does the uploading. This says with what permissions new files are created.Again see man umask on Linux/UNIX system, the idea is, that whatever bits you set in umask (the same notation as for chmod explained above) are excluded from the permissions on a newly created files - for example if you set your umask to 0023, your files will be created with all permissions for you, not writeable for your default group and not writeable neither executable by anybody else. It is usually bad idea to set the 0th bit here, since on directory creation it makes it non-executable which blocks entering the directory at all (for the set of users for which the bit is set, in the 0023 example for "anybody else").

In addition to this, it might be worth assigning default ACLs to the directory if the underlying filesystem supports them. That would allow finer grained access control (ACL stands for Access Control List, similar to the Windows one). See man setfacl for more information.

BIG FAT WARNING: It's not a good idea to make files world-writable! Keep the rights at the minimum that works.