http://www.rs6000.ibm.com/resource/
-rwxrwxrwx
This character string can be broken up into the three
permission sets:
-rwx rwx rwx
^ ^ ^
| | | Permissions for others
| |
| | Permission for users that have this group as
| their primary group or as part of their group set.
|
| Permissions for the owner of the file or directory
These commands also show an owner and a group for the file or
directory:
-rwxrwxrwx [some number] joe joegroup
^ ^ ^
| | |
permissions owner group
The displayed name for the owner is taken from /etc/passwd.
The file's inode stores the user id (a number). If you see a
number instead of a name, either the /etc/passwd file is not
readable or that user id is missing from the file. The name
of the group is taken from /etc/group. Again, only a number
is stored in the file's inode.
Then the system checks to see if you have the group listed as either your primary group or as part of your group set. If so, you get the group permissions, even if these permissions are more restrictive than the "other" set.
If you are not the owner or part of that group, you get the permissions for other.
The relationship of the directory to a file is:
| directory | --> | inode | --> | data |
| contains a list of the filenames and the pointers to the inodes that contain the permissions for the file | contains the permissions for the file and a pointer to where on disk the data resides | actual user data |
Directory permissions are required to find a file before opening it for use.
For a directory, permissions letters have these meanings:
| r | indicates the ability to read the list of files in a directory such as with the ls command. |
NOTE: You cannot execute a command inside the directory if the only permissions you have is to read the directory listing.
| x | indicates the ability to pass through the directory (search). This allows you operate on files in the directory if you already know the filenames. Without read permission, you cannot read the entries but are allowed to access them. To use a file the user must have search permission for ALL directories in the path. They must also have appropriate permission for the file itself. |
In general, both read (r) and search (x) are required for most directory operations.
| w | indicates the ability to create or delete files in the directory when coupled with the search (x) permission. If you have permissions to write at the directory level but no permissions on the file inside, you may still delete the file even though you may not modify the file. If you have only write permissions, you cannot change or modify the file. |
| t | indicates link permission. When set, this bit prevents any user except the owner of a file, a root user, or the owner of the directory from deleting the file, even though the permissions on the directory would otherwise allow it. In such a case, the search (x) bit is set for other. |
| T | means the same as lowercase t but the search (x) bit is not set for other. |
| s | is not used in the owner position. For the group position, this becomes the group inheritance bit (SGID). Any files created in this directory have the same group as the directory entry. In AIX, when a new file system is created, this bit is set by default. This also means the search (x) bit is set for the group. |
| S | is the same as the lowercase s but means the search (x) permission is not set for the group. |
For a file, permissions letters have these meanings:
| r | indicates the ability to read the file. |
| w | indicates the ability to change or modify a file. You cannot create or delete the file unless you have write permission for the directory. |
| x | indicates the ability to execute the file. |
umask 022NOTE: You do not use the equal sign (=) when setting umask.
umask does not set the execute bit on a text file or shell script, but only on a directory. To determine what umask to use, take the umask setting and subtract it from 777 for a directory or from 666 for a text file or shell script. Then, if you create a directory or text file, you see permissions as follows:
Example with umask 022:
Executing ls -l shows the following permissions:
| for a directory: | rwxr-xr-x |
| for a text file: | rw-r--r-- |
To use the chgrp command:
chgrp <new_group_name> <file_name>
To use the chown command:
chown <new_owner> <file_name>
or
chown <new_owner.new_group> <file_name>
CAUTION: If you are using ACLs on a file or directory, using the numeric mode of the chmod command will DISABLE the ACL.
The following general syntax for numeric mode should be run on one line as:
chmod [special bits][owner][group][other] (file_name or directory)
The numeric mode uses numbers for each position--owner,
group and other. For each position:
read (r) = 4
write (w) = 2
execute [or search] (x) = 1
These numbers are added together to get the numbers to use for the chmod command. For example:
| owner has read + write + execute | = | 4+2+1 | = | 7 |
| group has read + write | = | 4+2 | = | 6 |
| other has read | = | 4 | = | 4 |
To set the (special), bits, suid, sgid and link bits requires a fourth number for the chmod command.
suid = 4
sgid = 2
link = 1
To add the suid (set user id) permissions to the preceding example, the command is:
chmod 4764 <file_name>
To use the symbolic mode, you specify which position owner
(u), group (g), other (o) or all (a) to change and what
symbol to add (+) or subtract (-). To add read + write to
the owner use both:
chmod u+r u+w <file_name>
or
chmod u+rw <file_name>
If the sgid (set group id) bit is set on a directory, the
symbolic mode must be used to unset it:
chmod g-s <file_name>
The numeric mode will not produce an error but the sgid bit will still be set.
For further information on the chmod command, see InfoExplorer or the man page for chmod.
| PERMIT | Grants the specified access to the file or directory. |
| DENY | Restricts the specified access to the file or directory. |
| SPECIFY | Precisely defines the file or directory access. |
The acledit command is used to create an ACL. First you must set the EDITOR environment variable with the full path to your favorite text editor. For example:
export EDITOR=/usr/bin/vi.
Then use:
acledit file_name
This will bring up a screen like:
attributes:
base permissions
owner(rcunning): rwx
group(staff): r--
others: ---
extended permissions
disabled
To set the extended permissions, change the "disabled" setting
to "enabled":
extended permissions
enabled
Use the permit, deny or specify keywords to define the
extended permissions. The preceding example shows that only the
owner can write to this file. The group staff can read the
file and other has no permissions. To allow user joe to read
and write the file, use:
extended permissions
enabled
permit rw- u:joe
To allow group joegroup to read the file, use:
permit r-- g:joegroup
You can fine tune the permissions by combining the multiple
entries on the same line. If you want to give pete read and
write access ONLY, and if he is currently part of the system
group, use:
permit rw- u:pete, g:system
To add permissions for several users or groups, use separate
lines:
permit rw- u:joe
permit rw- u:pete
Further information on the acledit command appears in
InfoExplorer or the man pages.
Two other ACL commands can be used, aclget and aclput:
To copy the ACLs from one file to another, you can use:
aclget <file_name> | aclput <new_file_name>
Use the ls -el command to see if an ACL is set on a
file. ls -el .profile shows:
-rwxr-----+
The + in the last position means the file has
an ACL enabled.
CAUTION: Using the chmod command with numeric arguments will disable the ACL for a file or directory.
When a file system is created, the default permissions come from a proto file (see mkfs in InfoExplorer for more details) and the SGID (group inheritance) bit is set. The user's umask is not involved for file systems, but just for the underlying mount point.
NFS mounted file systems use a special user id called nobody. This UID is normally a very large number so as not to conflict with any real user id. Unless the NFS server has an entry in /etc/passwd for your user id (not text name), the permissions you have when you remote mount a filesystem is for the pseudo user id "nobody". If your user id happens to match some valid id on the remote system, you are now the owner of any files that owner created. This can lead to unpredictable results. If you need to be able to create and own files on the remote system, your local system and the server system must have matching user entries (both user name and the same id number) in the /etc/passwd files. The file system must also be exported as read and write.
The root user is a special case. Since root is user id 0 on all systems, without special protection any system that mounts the file system would become root on the server system. Because of this, the NFS filesystem must be exported with root access for any hostnames from which you require special root access. If the file system is not exported in this manner then root becomes user nobody and has the permissions of the "other" group.