-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.
The system also 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 detailed below.
Directory permissions are required to find a file before opening it for use.
For a directory, permissions letters have the following meanings.
NOTE: You cannot execute a command inside the directory if
the only permissions you have is to read the directory
listing.
In general, both read (r) and search (x) are required for
most directory operations.
For a file, permissions letters have these meanings:
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:
NOTE: If you have write and search permissions at the
directory level, you may delete the directory entry unless the
link permissions bit (t) is set on the directory.
What determines the permissions on a file or directory
when I create it?
Your user id (uid) is used to set the owner of the file.
Your primary group is used to set the group (unless the
directory in which the file is created has the sgid permission bit
set; then the group is the same as the group on the
directory entry). The id command can be used to see the uid and
primary group for that user. Your umask setting is used to
set the initial permissions. Type umask at the command line
to see the current setting. To change the umask setting, type umask
number, as in:
umask 022
NOTE: You do not use the equal sign (=) when setting umask.
| 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 Access Control Lists, (ACL), 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 (set user id), sgid and link bits requires a fourth number for the chmod command.
suid = 4
sgid = 2
link = 1
To add the suid 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 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.
************************************************************
SECURITY RISK
WARNING: Current UNIX(r) security manuals
warn SUID/SGID shell scripts are a major security risk and
are to be avoided. This document reintroduces a POTENTIAL
SECURITY RISK to your system!
************************************************************
A fix for a potential security risk dealing with the use of the SETUID and SETGID permission bits on shell scripts was included in AIX 3.1.7 (which corresponds to update level 2007). Prior to 3.1.7, when a shell script was executed whose permissions included the SETUID bit (set user-id), the shell script ran with the permissions of the shell script's owner. Similarly, if the SETGID bit (set group-id) was set, the shell script ran with the permissions of the shell script's group. Beginning with AIX 3.1.7, the SETUID and SETGID permission bits are no longer supported for shell scripts. This change does NOT affect compiled programs.
#!/bin/ksh
id
chown root shell.sh
chmod 4755 shell.sh
Prior to AIX 3.1.7, if an ordinary user named "joeuser" ran shell.sh, the output would be:
uid=200(joeuser) gid=200(staff) euid=0(root)
The euid=0(root) indicates that the user was effectively root while the shell script executed.
For AIX 3.1.7 and later, the output is:
uid=200(joeuser) gid=200(staff)
The SETUID bit no longer has any meaning for shell scripts. The means that the SETUID does not function as it does on other UNIX systems. Other versions of UNIX do pass the euid 0 to other kornshell scripts and child processes; thus, creating a security vulnerability unacceptable to AIX.
If your application requires the previous SETUID behavior, you can call the shell script from a small compiled program that has the SETUID bit set in its permissions.
main(int argc, char *argv[])
{
execvp("/path/shell.sh", argv); /* execute the shell script */
exit(1);
}
cc -o execsh execsh.c
chown root execsh
chmod 4755 execsh
The SETUID behavior has not changed for compiled programs, so execsh will effectively become root when it is executed, and will pass these credentials to shell.sh.
To have a non-root user execute a program with root permissions, use the following:
Put the following text in the file you just created.
main ()
{
setuid(0);
setgid(0);
system("/bin/mksysb -i /dev/rmt0");
}
cc umksysb.c -o umksysb
chmod 4755 umksysb
Access Control Lists (ACL) can be used to specify particular users that can access these files. This can be used with other commands as well.
Another example of a non-root user executing a program with root permissions is shown in the following steps.
myshutdown.c
Put the following text in the file myshutdown.c:
main()
{
setuid(0);
setgid(0);
system("/usr/sbin/shutdown -Fr");
}
cc myshutdown.c -o myshutdown
chmod 4755 myshutdown
NOTE: Making a program suid root only assigns uid 0 to the program. Additional code may be required to acquire root's environment using the setpcred and setpenv subroutines.
For further information on the chmod command, at AIX Versions 4.2 and earlier, 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 for AIX Version 4.2 and earlier or the man pages.
Two other ACL commands can be used, aclget and aclput:
To copy the ACLs from one file to another, use:
aclget <file_name> | aclput <new_file_name>
Use the ls -el command to see if an ACL is set on a
file. For example, the ls -el .profile command 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 at AIX Versions 4.2 and earlier 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 file system 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 created by that owner. 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 file system must be exported with root access for any host names from which you require special root access. If the file system is not exported in this manner root then becomes user nobody and has the permissions of the group other.
[ Doc Ref: 90605219514824 Publish Date: Dec. 18, 2001]