File permissions on the unix platform
Occasionally, you might have reason to change the permissions of a file. If you are not being allowed to edit a file or you want to keep yourself and/or others from modifying a file, you want to check the permissions of the file and see if they should be changed using the chmod unix command. Here's a key to the most common instances.
| Permissions | Code | What it means |
|---|---|---|
| -r--r--r-- | chmod 444 filename.do | read only for the owner, group and any user |
| -rw-r--r-- | chmod 644 filename.do | read and write for the owner, read for everyone else |
| -rw-rw-r-- | chmod 664 filename.do | read and write for the owner and group members, read for everyone else |
You can change the permissions of any file you own. If you do not own a file, you can gzip the file or gunzip the file to become the owner.
You are a member of the USDA group on Gromit and the PCUSDA group in the Mass Storage section of Statapps.
Statapps uses a slightly different permissions system known as ACLs (Access Control Lists). These ACLs are in effect in the AFS space (/afs/isis/depts/cpc/projects/usda/). ACLs control permissions to directories, not files. If you need these changed contact Phil Bardsley. The important thing to know about permissions on Statapps is:
The permissions for the owner are the only permissions that matter. Basically, the unix file permissions do not apply. It only matters what the owner's permissions are set to. On Statapps you are a member of the ACL group cpc:pcusda. Everyone in the cpc:pcusda group has all permissions (except administrative) to all subdirectories and thus all files as the owner of a file. So if a file's permissions are -rw-r--r-- anyone in the cpc:pcusda group can edit/delete that file even if they do not own it.
FOR STATAPPS ONLY:
| Permissions | Code | What it means |
|---|---|---|
| -r-------- | chmod 400 filename.do | read only for everyone in cpc:pcusda |
| -rw------- | chmod 600 filename.do | read and write for everyone in cpc:pcusda |
Example showing how to make the child08 SAS7 data set read only so that it cannot be easily deleted or accidentally overwritten by SAS:
$ ll drwxrwxr-x 2 danb employee 2048 Mar 2 10:47 ./ drwxrwxr-x 4 danb employee 2048 Jul 25 2000 ../ -rw------- 1 danb employee 50176 Jul 25 2000 child08.sas7bdat -rw------- 1 danb employee 2812 May 23 2000 child08a.sas7bdat.gz -rw------- 1 danb employee 5023 Apr 20 2000 child09.sas7bdat.gz -r-------- 1 danb employee 33792 Mar 2 10:47 child23.sas7bdat -rw-r----- 1 danb employee 25469 Feb 26 15:35 child23c.log $ chmod 400 child08.sas7bdat $ ll drwxrwxr-x 2 danb employee 2048 Mar 2 10:47 ./ drwxrwxr-x 4 danb employee 2048 Jul 25 2000 ../ -r-------- 1 danb employee 50176 Jul 25 2000 child08.sas7bdat -rw------- 1 danb employee 2812 May 23 2000 child08a.sas7bdat.gz -rw------- 1 danb employee 5023 Apr 20 2000 child09.sas7bdat.gz -r-------- 1 danb employee 33792 Mar 2 10:47 child23.sas7bdat -rw-r----- 1 danb employee 25469 Feb 26 15:35 child23c.log
In the above example it only matters what the first set of file permissions are set to. It doesn't matter that "danb" owns the file. It doesn't matter that the "employee" group has permissions. The only users allowed in this directory are the members of the cpc:pcusda group. This group has permissions set up by the ACLs administered by Phil. Other people with administrative permission are accessed through cpchelp@unc.edu.
