| The permissions of all the files in the system would normally be set by the system administrator to fit in with the site security policy (which all sites should have). We will be looking at how to define default permissions to new files that are created, but first we will look at how to alter the permissions of an existing file. The first thing we need to know is that only the owner of a file (or root) can change the permissions of a file, and the command we use is chmod (which is short for "change mode" as a file's permissions can also be referred to as its mode). There are two ways that the permissions of a file may be changed with chmod. The first uses absolute syntax and the second symbolic syntax. Consider the following example: hydrogen$ ls -l info -rw------- 1 dbutler slackers 47 Jul 12 11:31 info hydrogen$ The file called info is owned by user dbutler and belongs to the group slackers. The permissions show that dbutler can read the file and make changes to it, but no one else may do anything with it: hydrogen$ chmod 664 info hydrogen$ ls -l info -rw-rw-r-- 1 dbutler slackers 47 Jul 12 11:31 info hydrogen$ After running the chmod command with a parameter of 664, the permissions now show that not only can dbutler read and alter the file, but so can the other users belonging to the group slackers. All other users on the system can now read the file, but cannot alter it. No one is able to execute the file. So, how does the number 664 translate into a set of permissions? To do this, we give each of the characters "r," "w," "x," and "-" a numeric value and add these values within each user class. The value assigned to each letter is as follows: So rwxrwxrwx would equal 4+2+1, 4+2+1, and 4+2+1 or 777 (but NOT 21). Likewise rw-r--r-- would be represented by 644 (4+2+0, 4+0+0, and 4+0+0). These numbers are actually an octal representation of the permissions. The following segment of shell script code can be used to demonstrate this: echo "Enter permissions (e.g. rwxrw-r--):\c" read perms bin_perms=$(echo $perms | sed 's/[rwx]/1/g s/-/0/g') octal_perms=$(echo "obase=8\nibase=2\n${bin_perms}" | bc) echo "Your permissions translate to $octal_perms" The sed command converts the permissions into a binary number; this is then converted to octal using bc. Using the absolute syntax, as we have here, is useful if you want to set the permissions of a file to a specific value and are not concerned with what they were originally. Sometimes, however, you may want to change a specific part of the permissions without altering the other parts. For example, if you wanted to add read and write permission to the group part of all the files in the current directory, you could not do it using the above method without first making a note of each file's existing permissions. The way we would do this is by using chmod with symbolic syntax: hydrogen# ls -l total 476 drwxrwxr-x 5 adm adm 512 Jul 7 17:47 acct -rw------- 1 uucp bin 0 Jul 7 15:39 aculog -r--r--r-- 1 root root 28 Aug 22 21:52 lastlog drwxr-xr-x 2 adm adm 512 Jul 7 15:38 log -rw-r-r-- 1 root root 101744 Aug 22 21:52 messages drwxr-xrwx 2 adm adm 512 Jul 7 15:38 passwd drwxrwxr-x 2 adm sys 512 Jul 7 17:47 sa drwxr-xr-x 2 root sys 512 Jul 7 16:35 sm.bin drwxr-xr-x 2 root sys 512 Jul 7 15:38 streams -rw------- 1 root root 139 Aug 14 23:15 sulog -rw-r--r-- 1 root bin 3348 Aug 22 22:56 utmpx -rw-r--r-- 1 adm adm 103788 Aug 22 21:52 wtmpx hydrogen# The following command uses the symbolic syntax to change only the group class of the permissions: hydrogen# chmod g+rw * hydrogen# ls -l total 476 drwxrwxr-x 5 adm adm 512 Jul 7 17:47 acct -rw-rw---- 1 uucp bin 0 Jul 7 15:39 aculog -r--rw-r-- 1 root root 28 Aug 22 21:52 lastlog drwxrwxr-x 2 adm adm 512 Jul 7 15:38 log -rw-rw-r-- 1 root root 101744 Aug 22 21:52 messages drwxrwxrwx 2 adm adm 512 Jul 7 15:38 passwd drwxrwxr-x 2 adm sys 512 Jul 7 17:47 sa drwxrwxr-x 2 root sys 512 Jul 7 16:35 sm.bin drwxrwxr-x 2 root sys 512 Jul 7 15:38 streams -rw-rw---- 1 root root 139 Aug 14 23:15 sulog -rw-rw-r-- 1 root bin 3348 Aug 22 22:56 utmpx -rw-rw-r-- 1 adm adm 103788 Aug 22 21:52 wtmpx hydrogen# When we use this method to change a file's permissions we can use the letters "u" (for user class), "g" (for group class), "o" (for other class), and "a" (for all classes), followed by a "+" (to add a permission), "-" to remove a permission, and "=" to set a permission. Full details of this syntax can be found in the chmod man page. Default Permissions When a file is first created, it will be given a default set of permissions. The default permissions are controlled using the umask command and are stored in the environment of each shell process (see Chapter 5, "Shells"). This means they are usually set in /etc/profile to provide a system-wide setting or within each user's profile to allow users to have different default permissions. Seasoned administrators tend to refer to this process as setting the user's umask, rather than setting the user's default permissions. The umask command can either be run with a single parameter or with no parameter. If run with no parameter, it will return the umask setting for that shell session. If run with a parameter, it will set the current shell's umask to be the value of the parameter. The parameter supplied should be an octal number, which will be used as a mask to set the default permissions when a file or directory is created. The umask value is masked against the octal numbers 666 when creating a file and 777 when creating a directory. If we were to set the umask to 22, it would be masked against 666 to give 644 when a file was created. This would have the following effect: hydrogen# umask 22 hydrogen# echo "Hello world" >fred hydrogen# ls -l fred -rw-r--r-- 1 root other 12 Jun 30 12:11 fred hydrogen# mkdir bill hydrogen# ls -ld bill drwxr-xr-x 2 root other 69 Jun 30 12:12 bill hydrogen# Hopefully, the reason for handling default permission using a mask is apparent from the example above. It means that files will always be created with no execute permission, and directories will always be created with execute permissions (otherwise you would have to do a chmod on each newly created directory before you could change into it). This also means that newly created files cannot be accidentally executed if their name is typed at the shell prompt. File Ownership When a file is created on a Solaris server, it will take on the ownership and group of the user that created it. hydrogen$ id uid=1001(msmith) gid=10(staff) hydrogen$ echo "Hello world" >file1 hydrogen$ ls -l file1 -rw-r--r-- 1 msmith staff 12 Aug 8 14:58 file1 hydrogen$ In the above example, the user msmith has created a file, so it is owned by msmith and in the group staff, as this was the primary group of msmith when the file was created. If msmith is moved into a different group after creating the file, it will not affect the group that the file belongs to. Both the owner of the file and the group to which it belongs are stored in the file's inode (see Chapter 6, "The Filesystem and Its Contents"). After creating the file, the user msmith is free to change the ownership of the file and the group to which it belongs because msmith owns it (only root or a file's owner may do this). The command for doing this is chown, which takes as arguments the user to change the ownership to and the file (or a list of the files) to change. It also has a "-R" flag which is very useful for changing ownership of all files (and directories) below a specific directory. The command chgrp works in the same way, but changes the group of the file rather than the owner: hydrogen$ ls -l file1 -rw-r--r-- 1 msmith staff 12 Aug 8 14:58 file1 hydrogen$ chown jgreen file1 hydrogen$ ls -l file1 -rw-r--r-- 1 jgreen staff 12 Aug 8 14:58 file1 hydrogen$ The trouble is that once the ownership has been given away to another user, the original user is no longer the owner and cannot change the group or the ownership back to him or herself: hydrogen$ ls -l file1 -rw-r--r-- 1 jgreen staff 12 Aug 8 14:58 file1 hydrogen$ chgrp other file1 chgrp: file1: Not owner hydrogen$ chown msmith file1 chown: file1: Not owner hydrogen$ In practice, if non-root users want to change the owner and group of one of their files, they should change the group first or do both at the same time with a command similar to this: hydrogen$ ls -l file1 -rw-r--r-- 1 jgreen staff 12 Aug 8 14:58 file1 hydrogen$ chown jgreen:other file1 hydrogen$ ls -l file1 -rw-r--r-- 1 jgreen other 12 Aug 8 14:58 file1 hydrogen$ Because users can only change the ownership of files they own, and once they have given away ownership they cannot do it again, it is more likely that file ownership and group changes are performed by the system administrator. The more recent versions of Solaris will, by default, only allow file ownerships to be changed by root and will only allow a file's group to be changed by the owner to another group to which the user already belongs. If you tried the above examples and were unable to change the file ownership, then this is the likely cause. If you want to allow users to be able to change the ownership of their files, then add the following line to the /etc/system file and reboot: set rstchown = 0 To stop users from being able to change ownership of their files, set rstchown to "1" instead of "0" (or comment out the whole linethe comment character is an asterisk). The /etc/system file is covered in more detail in Chapter 21, "Kernels and All About Them." Sticky Bits Occasionally, you may have come across a file or directory whose permissions contained something other than the "r," "w," "x," or "-" that we looked at earlier. These additional characters tend to be called "sticky bits." In fact, some of them are sticky bits, but others are setuid (set user ID) or setgid (set group ID) bits. Sticky bits and setuid/setgid bits can only appear in the part of the permissions that would normally hold an "x," and they will be either of the letters "s" or "t." The letter "s" can occur in either the user or group part of the permissions, while the "t" can only appear in the other part. The meaning of these letters is different depending on whether they are applied to a file or a directory. We will look at the effect of the letter "t" (which is the only one that should be called the "sticky bit"). The Sticky Bit If a directory has the sticky bit set, this affects the rules for removing or renaming files within that directory. If it is set, a file within such a directory can only be removed or renamed if at least one of the following conditions is met: The user is the owner of the file. The user is the owner of the directory. The user has permission to write to the file. The user is the super-user (root).
One directory that would normally have the sticky bit set is /tmp: hydrogen# ls -ld /tmp drwxrwxrwt 6 sys sys 313 Jul 1 16:45 /tmp hydrogen# This is to prevent users from removing files created by other users. It is recommended that all directories used by many users have the sticky bit set. You will notice that because the underlying directory permissions are 777, anybody is allowed to create files in /tmp, but this also means that anybody is allowed to remove files from the directory. Thus, by setting the sticky bit we ensure that files created in that directory are safe from other users despite the directory's underlying permissions. The fact that the sticky bit shown above has a lowercase "t" tells us that the execute permission is also set in this location. If the execute bit were not set, the permissions would contain a capital "T" instead; but this would not make sense, as it would prevent those users that fit into the other category from changing into that directory. If you create a public directory and you wish to set the sticky bit, the simplest way is to use chmod +t, which will add the sticky bit, while leaving the remaining permissions as they were: hydrogen# mkdir public_dir hydrogen# ls -l total 8 drwxr-xr-x 2 root other 69 Jul 1 17:32 public_dir hydrogen# chmod +t public_dir hydrogen# ls -l total 8 drwxr-xr-t 2 root other 69 Jul 1 17:32 public_dir hydrogen# You can also set the sticky bit using the absolute method by placing a "1" in front of the three-digit octal number: hydrogen# mkdir public_dir hydrogen# ls -l total 8 drwxr-xr-x 2 root other 69 Jul 1 17:40 public_dir hydrogen# chmod 1777 public_dir hydrogen# ls -l total 8 drwxrwxrwt 2 root other 69 Jul 1 17:40 public_dir hydrogen# chmod 1770 public_dir hydrogen# ls -l total 8 drwxrwx--T 2 root other 69 Jul 1 17:40 hydrogen# This example of chmod shows us changing the permissions so that the sticky bit is set, but we only want certain users to be able to use the directory. To achieve this, we have removed the permissions for others (not the group other, but everybody who is not root and not in the group other) to do anything with the directory. You may have noticed that the last update time of the directory did not change each time we changed its permissions. This is because the permissions of a file or directory are not stored inside the file itself but in its inode, as we mentioned earlier. We have seen why we might set the sticky bit on a directory, but not why we might want to set it on a file. You may also be wondering why on earth it is called a sticky bit, since nothing we have seen so far can be associated with the word "sticky." In fact, the term "sticky" arose many years ago when computers did not have much memory. Each time a program was run (either a compiled program or a shell script) it needed to be loaded into memory. It would run for its allotted time slice and then another program would run for its time slice. This process occurs for all programs, whether they are system processes or user-initiated programs. If there is enough memory on the system to hold all the currently running processes, things are fine; if not, then the system will copy a process out of memory to a special area of disk called swap (see Chapter 7, "Swap Space"). This is fine, since next time that process needs to run it will be copied back into memory from swap. This means that every process will still get its chance to run, but the performance of the server may not seem very good to the users, as swapping processes between memory and disk takes time. If the system is fairly heavily used, you could get a situation where lots of users are running the same application but are getting poor responses, since other processes cause this application to keep getting swapped out to disk all the time. This could be fixed by setting the sticky bit of the program, which would cause it to stick in memory (hence the name). Setting the sticky bit would not guarantee that the process would never be swapped out, but when the system did need to swap a process out it would always try and find one without the sticky bit set. Hopefully this has given you a bit of background into why this is called the sticky bit, but because modern Solaris systems do not have the same memory constraints (or the same method of managing memory) you will find that setting the sticky bit on programs is no longer required. If you wish to search your filesystems to see if any of your files or directories have it set, you can use the following find command: hydrogen# find / -perm -1000 -exec ls -ld {} \; drwxrwxrwt 3 root mail 512 May 19 11:11 /var/mail drwxrwxrwt 3 bin bin 512 Apr 22 10:10 /var/preserve drwxrwxrwt 3 bin bin 512 Apr 29 18:13 /var/spool/pkg drwxrwxrwt 50 sys sys 1536 Aug 6 10:02 /var/tmp drwxrwxrwt 2 root root 512 Dec 19 2000 /var/dt/tmp drwxrwxrwt 6 sys sys 275 Aug 6 17:15 /tmp drwxrwxrwt 2 root root 207 Aug 6 10:01 /tmp/.rpc_door hydrogen# You should find that the sticky bit is only set for directories, unless you have a very old Solaris system, in which case you may find some programs with it set. Setuid and Setgid We have seen what happens when a file or directory has a "t" in the permissions. Now we will look at why we might want to use the letter "s." The "s" may be placed in either the owner or the group part of the permissions. Like the "t," it can only go in the execute position. Before we go into detail about what the setuid and setgid bits are for, we will look at a program that has the setuid bit set and see what the program does. The program in question is the passwd command, which is used by users to change their own passwords and by the root user to change anybody's password (see Chapter 3, "User Administration"). The permissions of this program are as follows: hydrogen# ls -l /bin/passwd -r-sr-sr-x 3 root sys 99824 Sep 9 1999 /bin/passwd hydrogen# We can see that the permissions include a letter "s" in the user and group parts. This means that this file has both the setuid and the setgid bits set. Because the letter is lowercase, we know that the execute permission is also set, because it would be a capital letter if it wasn't. Because the file is owned by the root user, we also know that if the execute bit was not set, root would not be able to run the passwd command, which wouldn't make much sense at all. As discussed in Chapter 3, Solaris stores all user passwords in a file called /etc/shadow. Even though the passwords are encrypted, this file is crucial to the security of the systems, so it has very restrictive permissions. hydrogen# ls -l /etc/shadow -r-------- 1 root sys 277 Jan 14 2001 /etc/shadow hydrogen# This means that only the root user is able to read the contents of this file, and no one is allowed to do anything else to it. In fact, the root user may also write to the file because root is able to read or write from any file regardless of its permissions. Let's now go back to the passwd command and see what happens when a normal user tries to change a password: $ id uid=1001(msmith) gid=10(staff) $ passwd passwd: Changing password for msmith Enter login password: (current password typed here) New password: (new password typed here) Re-enter new password: (new password typed again) passwd (SYSTEM): passwd successfully changed for msmith $ ls -l /etc/shadow -r-------- 1 root sys 277 Aug 6 17:34 /etc/shadow $ We can see that the command prompted the user for a new password and that the shadow file has been updated, but this should not have happened because the user msmith does not have permission to write to it (and nor does any other user). The reason this command worked is that the passwd command has the setuid bit set. The setuid bit makes Solaris run the command with the same privileges as the person who owns the command, which in this case is root (although it may not always be). Each process that runs will have a user ID (UID) and a group ID (GID) associated with it which will always be equal to the UID of the user running the process and the GID of the group they are in. A process may also have an effective user ID (EUID) and an effective group ID (EGID). The EUID and EGID are set when the setuid or setgid bits are used, and these will override the process UID and GID. Note: The passwd program also has its setgid bit set, which means that the program will also run with the group privileges of the group that it belongs to. However, the setuid bit along with root ownership is enough to be able to update the shadow file. This is clearly a neat way of enabling users to perform tasks that update system files, but it is also something that the system administrator needs to be very wary of, as it could be used by unscrupulous individuals to do things they shouldn't. This is because it is also possible to use the setuid and setgid bits on some shell scripts, so if users were able to modify a setuid shell script that was owned by root, they would be able to put any command they liked into it, and it would run with root privileges. Solaris will only allow you to use setuid and setgid on Korn Shell (ksh) scripts, as this feature was disabled from the Bourne shell some time ago. The following simple script demonstrates the effect of using setuid and setgid on a shell script. First, we will run it with no setuid or setgid and then look at the difference setuid and setgid make: hydrogen$ id uid=1001(msmith) gid=10(staff) hydrogen$ ls -l showid -r-xr-xr-x 1 root other 31 Aug 23 12:06 showid hydrogen$ cat showid #! /bin/ksh id touch test_file hydrogen$ ./showid uid=1001(msmith) gid=10(staff) hydrogen$ ls -l test_file -rw-r--r-- 1 msmith staff 0 Aug 23 12:09 test_file hydrogen$ Now we will add setuid and setgid to the permissions (which can only be done as root, of course) and let msmith run the script again: hydrogen# rm test_file hydrogen# chmod ug+s showid hydrogen# ls -l showid -r-sr-sr-x 1 root other 31 Aug 23 12:06 showid hydrogen# Back to msmith's login session: hydrogen$ ./showid uid=1001(msmith) gid=10(staff) euid=0(root) egid=1(other) hydrogen$ ls -l test_file -rw-r--r-- 1 root other 0 Aug 23 13:17 test_file hydrogen$ We now see that although the process still has the UID and GID of msmith, because the setuid and setgid bits were set the process also has an EUID and an EGID equal to the owner and group of the script. Because the EUID and EGID override the UID and GID, the file created gets the owner and group it would have received if root was actually running the script. If you ever need to implement any setuid or setgid scripts, make sure that nobody has permission to write to them, as this used to be a potential security loophole. Now, however, you will find that if a user does edit a setuid to root script, the setuid will disappear when the user saves the file. It is, however, advisable for system administrators to keep an eye on which files on their systems have the setuid or setgid bits set. If you have programs other than those provided as part of Solaris with these bits set, be sure that you trust what they do. Likewise, if you do need to write your own setuid program, ensure that you consider all the security implications when you write it and, if possible, try to achieve what you need to by using setgid rather than setuid. At the end of this section, we will look at how you can find all the setuid and setgid files on your systems. If you are using Solaris 8 or higher, there is less need to make use of setuid shell scripts thanks to the introduction of RBAC (which is covered in Chapter 3, "User Administration"). Setting the setuid and setgid bits is similar to setting the sticky bit. We can set the setuid bit using chmod u+s and set the setgid using chmod g+s. However, for security reasons, in addition to the fact that the setuid and setgid bits will disappear if the file is edited, as mentioned above, they will also disappear if the owner or group of the file is changed (unless it is root running the command). It does not make sense for a file to have its setuid or setgid bit set without also having the equivalent execute bit set. If you try to do this using the symbolic method of changing permissions, you will get the following error message: hydrogen# ls -l test_file -rw-r--r-- 1 root other 0 Aug 10 14:22 prog hydrogen# chmod g+s test_file chmod: WARNING: Execute permission required for set-ID on execution for test_file hydrogen# All the special permissions (setuid, setgid, and sticky bit) can also be set using the absolute method by placing an additional octal number in front of the three-digit octal permission you wish to set. In the section on setting the sticky bit, you can see that placing a "1" in front of the three-digit octal permission will set the sticky bit. The values that need to be used are shown below: t=1 (sticky bit) s=2 (setgid bit) s=4 (setuid bit)
So if we wanted to change the permission of a file to have the setuid bit set, we would put a "4" in front of the permissions. If we wanted to set both the setuid and setgid bits, we would put a "6" in front. hydrogen# chmod 6555 prog hydrogen# ls -l prog -r-sr-sr-x 1 root other 861 Aug 9 16:38 prog hydrogen# It is highly unlikely that you would find a directory with the setuid bit set, but you may find one with the setgid bit set. If a directory has the setgid bit set, it means that all files created under that directory will be owned by the group which owns the directory, rather than the group of the user creating the file. Finding Setuid and Setgid programs It is very important for the system administrator to know which files have the setuid and/or setgid bits set. The following find commands will produce a list of setuid/setgid files shown in ls -l output format so you can see who owns them and which group they belong to. You may prefer to redirect the output into a file, as there could be quite a lot of it. To find files that have the setuid bit set use: find / -perm -4000 -exec ls -ld {} \; To find files that have the setgid bit set use: find / -perm -2000 -exec ls -ld {} \; To find files that have both the setuid and setgid bits set use: find / -perm -6000 -exec ls -ld {} \; In each of the above find commands, we have put a minus sign before the permissions to ensure that we are finding files that include the octal permissions shown. This means when we search for files with the setuid bit set it will also find files with the setgid bit set, but only if the setuid bit is also set. If we did not put a minus sign in front of the permissions, we would be searching for files with those permissions exactly, which would not be very helpful as there are likely to be no files on the system with permissions set to 4,000 (i.e., ---S------). We are using the "-exec" option of find, which will cause find to execute the command following it for each file that matches the search pattern. Therefore, find will execute the command ls -ld each time it finds a file, supplying the file as the argument to ls. We need to use the "-d" option because if the file found by find is actually a directory, ls will list the files inside the directory rather than the directory itself. The following example shows an abbreviated list of what you may expect to see: hydrogen# find / -perm -4000 -exec ls -ld {} \; -r-sr-xr-x 1 root bin 650720 May 6 1999 /usr/lib/sendmail -rwsr-xr-x 1 root adm 5304 Sep 1 1998 /usr/lib/acct/accton -r-sr-xr-x 1 root sys 27628 Oct 6 1998 /usr/bin/sparcv7/ps -r-sr-xr-x 2 root bin 11528 Oct 6 1998 /usr/bin/sparcv7/uptime -r-sr-xr-x 2 root bin 11528 Oct 6 1998 /usr/bin/sparcv7/w -rwsr-xr-x 1 root sys 35916 Oct 6 1998 /usr/bin/at -r-sr-xr-x 1 root bin 17044 Oct 6 1998 /usr/bin/crontab -r-sr-xr-x 1 root bin 14352 Oct 6 1998 /usr/bin/eject -r-sr-xr-x 1 root bin 29292 Oct 6 1998 /usr/bin/login -rwsr-xr-x 1 root sys 7736 Oct 6 1998 /usr/bin/newgrp -r-sr-sr-x 3 root sys 99824 Sep 9 1999 /usr/bin/passwd -r-sr-sr-x 3 root sys 99824 Sep 9 1999 /usr/bin/yppasswd <lines removed for clarity> hydrogen# You will notice that some files found also have the setgid bit set, but the output will not contain all the files with this bit set as we have told find to search for files with the setuid bit set. If you wish to be able to find all files with the setuid or setgid bit set, you can use the following find command: hydrogen# find / \( -perm -4000 -o -perm -2000 \) -exec ls -ld {} \; | pg -r-sr-xr-x 1 root bin 6264 Sep 1 1998 /usr/bin/volcheck -r-sr-sr-x 1 root sys 24392 Sep 9 1999 /usr/dt/bin/dtaction -r-sr-xr-x 1 root bin 11176 Sep 1 1998 /usr/bin/volrmmount -r-xr-sr-x 1 bin mail 1552660 Aug 2 1999 /usr/dt/bin/dtmail -r-xr-sr-x 1 bin mail 555992 Aug 12 1999 /usr/dt/bin/dtmailpr -r-sr-xr-x 1 root bin 383552 Aug 12 1999 /usr/dt/bin/dtprintinfo -r-sr-xr-x 1 root bin 147908 May 6 1999 /usr/dt/bin/dtsession drwxr-sr-x 5 root bin 512 Oct 18 2000 /usr/dt/lib/fdl drwxr-sr-x 3 root bin 512 Oct 18 2000 /usr/dt/lib/fdl/adobe <lines removed for clarity> hydrogen# Now we can see all the files that have either the setuid, setgid, or both bits set, but we also get the directories that have their setgid bit set. We can remove these by adding the option "-type f" to the above find command: find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -ld {} \; >/tmp/permrep.out The above command will find all files (but not directories) that have their setuid and/or setgid bit set and will produce an ls -ld listing of these files in the output file /tmp/permrep.out. If you find anything suspicious in the output file, be sure to copy it out of /tmp to ensure that you don't lose it should the system reboot. File Locking One special permissions bit we have not yet looked at enables files to be locked by Solaris when they are accessed by certain applications. The permission is represented by the letter "l" and is located in the group execute position of a file's permissions: hydrogen# touch test_file hydrogen# ls -l test_file -rw-r--r-- 1 root other 0 Aug 10 14:35 test_file hydrogen# chmod g+l test_file hydrogen# ls -l test_file -rw-r-lr-- 1 root other 0 Aug 10 14:35 test_file hydrogen# The file-locking bit can be set using absolute permissions in the same way you would set setgid, but with no execute bit set: hydrogen# chmod 2666 test_file hydrogen# ls -l test_file -rw-rwlrw- 1 root other 0 Aug 10 14:35 test_file hydrogen# This means it is not possible to have the setgid bit set as well as file locking. It also means that if you search for files with the setgid bit set using the "-perm" option of find, the output will also include any files that have file locking set. | 
