Solaris File System Security and Permissions

You can control the access that users have to files and directories on SunLink Server computers by securing them through permissions.

Every permission that you set specifies the access that a group, user, or others can have to the directory or file. For example, when you set Read permission for the group called Coworkers on the file MY_IDEAS.DOC, the users in that group can display the file's data and attributes, but they cannot edit the file or delete it.

The SunLink Server program offers the following permissions that you can set on directories and files for users, groups, and others:

• Read (R) - Allows individuals or groups to see the file or contents of a folder, but not to edit, delete, or execute it.

  ---

  Note -

  In the Solaris operating environment, Read permission is far more restrictive than the similarly named permission in the Windows NT environment. In the Windows NT environment, Read permission is advisory only--a user on a Windows NT client machine would still be able to edit a nominally Read-only file. In the Solaris environment--the environment in which all SunLink Server files and directories are stored and managed--a user would be prohibited from editing a Read-only file. You can override the more restrictive Solaris permissions to become fully compatible with Windows NT-style permissions, however. See "How to Set Solaris File System Integration Policies" for instructions.

  ---

• Write (W) - Allows individuals or groups to see and edit the file or contents of a folder.

• Execute (X) - Allows individuals or groups to run executable programs, but not to see or edit the code itself.

• Full Access (RWX) - Allows individuals or groups to see, edit, and run any file, directory, or executable program so designated.

• No Access - Denies all permission (achieved by not setting any of the above permissions).

You establish permissions on files and directories, but the permissions that you establish actually affect the computer users. The Solaris operating environment differentiates among people to whom the permissions apply:

• User - If you own a Solaris system file or directory, you can assign it access permissions for yourself. For example, to prevent unauthorized users from executing a program, you can assign execute permissions to yourself only.

• Group - This setting, in the context of the SunLink Server program, is not the same as group permissions in the Solaris operating environment. In the Solaris file system, group permissions grant to other members of your Solaris group access to files and directories that you own. In the SunLink Server environment, however, Windows NT groups--not Solaris groups--are created, and Solaris group permissions have no effect on them.

• Other - You can assign access permissions to files and directories that you own for all Solaris system users other than yourself and the users in your group. Depending on your needs, you can allow these other users to read or change your files and directories or you can prevent such access. Restricting access to others does not affect your own access to the files and directories.

Standard permissions are combinations of individual permissions that depend on the nature of the files and directories and the makeup of groups. To work effectively with SunLink Server file and directory security, keep the following points about setting permissions in mind:

• Users cannot use a directory or file unless they have been granted permission to do so or belong to a group that has permission to do so.

• Permissions are cumulative, except that setting a No Access permission--not indicating Read, Write, or Execute on a file or directory--overrides all other permissions. For example, if the Coworkers group has Write permission for a file while the Finance group has only Read permission, and John is a member of both groups, John will be granted Read and Write permissions. However, if you remove the Finance group's only permission for the file to effectively become No Access, John will not be able to use the file--even though he is a member of a group that has access to it.

• When you create files and subdirectories in a SunLink Server directory, they inherit permissions from the directory. For example, if you add a file to a directory that allows the Coworkers group Write permission and the Finance group Read permission, the same permissions will apply to the file.

• The user who creates a file or directory is ordinarily the owner of that file or directory--though you can change that default. The owner can control access to the file or directory by changing the permissions set on it.

• The easiest way to administer security is to set permissions for groups, not individual users. Typically, a user needs access to many files. If the user is a member of a group that has access to the files, you can terminate the user's access by removing the user from the group rather than by changing the permissions on each of the files. Note that setting permission for an individual user does not override the access granted to the user through groups to which the user belongs.

  ---

  Note -

  When you copy SunLink Server files or directories, security permissions set on them are discarded in addition to ownership and auditing information. The files inherit a new set of permissions from the directory into which you have copied them. If the new directory does not specify permissions for files, only a file's owner (the person who copied the file) will have permission to use the file.

  ---

In addition to files and directories, shares carry their own permissions in a Windows NT environment. In case of permission conflicts among files, directories, and shares, clients see the most restrictive permissions among the conflicting sets.

Ownership of Files and Directories

Every file and directory has an owner. The owner controls how permissions are set on the file or directory and can grant permissions to others.

When a file or directory is created, the person creating the file or directory automatically becomes its owner. It is expected that administrators will create most files on network servers, such as when they install applications on the server. Therefore, most files on a server will be owned by administrators, except for data files created by users and files in users' home directories.

Ownership can be transferred in the following ways:

• The current owner can grant an implied ownership ability to other users by setting Write permission on the files or directories for Group or Others. This enables other people to copy the file, and "inherit" ownership of the duplicate.

• An administrator can take ownership of any file on the computer at any time. For example, if an employee leaves the company suddenly, the administrator can take control of the employee's files, no matter what permissions have been set.

  ---

  Note -

  Although an administrator can take ownership, the administrator cannot transfer ownership to others. This restriction keeps the administrator accountable.

  ---

The administrator also can take file ownership by using the net perms command. For more information, type net help perms at the SunLink Server command prompt.

In addition to files and directories, computer processes also have an owner. A computer process is initiated whenever an executable program is run, and the process is known to the system by a unique identifier. In the Solaris environment, this is called a Process Identifier, or PID.

Unlike file or directory ownership, however, process "ownership" changes whenever the program is executed. While an executable program--a spreadsheet, for example--is originally owned by the person who installed it on the network, its User and Group PID ownership changes when a person runs it. The spreadsheet process owned by root at installation will now be owned by the user and the user's group at execution. Because this change in process ownership has security implications, the SunLink Server program enables you to regulate it.

File-locking is also an important security concern, particularly in your heterogeneous environment of Windows NT and Solaris. While SunLink Server software accords the same file-locking security on network-based files and directories as Windows NT does, locked files may still be accessible directly from a Solaris computer account. SunLink Server software enables you to preclude that from happening, though it is not set by default as it may degrade overall system performance. If your network includes users who will access files from both Windows NT and Solaris network client machines, you should change this setting to honor Windows NT file-locking from Solaris accounts. See "How to Set Solaris File System Integration Policies".

During SunLink Server installation, users and groups who will be associated with the SunLink Server program were added to the system's local password and group files. If your site uses a Solaris name service such as NIS or NIS+ in the Solaris environment, you should put the group information into the name service maps. When creating files from a Windows NT Workstation and writing to a directory on the Solaris system, the owner is the user who creates the file and the default group is DOS---. While the user information is, in fact, retrieved from the name service maps, the group information is correctly displayed only if the listing of the file is performed on the SunLink Server system itself (default lookup: files nis). If these files are being viewed from another Solaris system, the group id will not be resolved correctly. By putting the group information into the name service maps, you allow the files to be consistent between the local system files and the maps.

SunLink Server Manager Security

Another security consideration involves users' privileges to administer the SunLink Server program by way of the SunLink Server Manager tool. You can choose settings that affect security on subsequent SunLink Server Manager sessions. Data Integrity uses public key signatures to protect data passed between the server and the client. Authentication takes place behind the scenes and involves rechecking credentials with each transaction. See "How to Secure SunLink Server Manager Transactions".