Managing Access to Files and Directories

On a traditional UNIX system, file access is controlled by granting permissions to the file owner, the file’s group, and all other users. These can be set with the chmod command and displayed with the ll (ls -l) command. (See chmod(1) and ls(1).

Access Control Lists (ACLs) give you a more precise way to control access to files than you have with traditional UNIX file permissions. ACLs allow you to grant or restrict file access in terms of individual users and specific groups, in addition to the traditional control.

Both HFS and JFS file systems support ACLs, but they use different mechanisms and have somewhat different semantics.

HFS ACLs are described in “Using HFS Access Control Lists (ACLs)”.
JFS ACLs are described in “Using JFS Access Control Lists (ACLs)”.
See “Comparison of JFS and HFS ACLs” for more about the differences.

Using HFS Access Control Lists (ACLs)

HFS ACL permissions are set with the chacl command and displayed with the lsacl command. (See chacl(1) and lsacl(1).)




	IMPORTANT: You must use chmod with its `-A` option when working with files that have HFS ACL permissions assigned. Without the `-A` option, chmod will delete the ACL permissions from the file. The syntax is: `chmod` `-A` `mode` `file` ...

The chacl command is a superset of the chmod command. Any specific permissions you assign with the chacl command are added to the more general permissions assigned with the chmod command.

The simple form of the chacl command is:

chacl 'user.group operator mode' filename...

where:

user

is the user’s login name; a percent sign (%) means all users.

group

is the user’s group; a percent sign (%) means all groups.

operator

is one of:

+: Add to the current permissions.
-: Delete from the current permissions.
=: Change the permissions to those given.

mode

is zero or more permissions: read (r), write (w), and execute/search (x).

The apostrophes (') are used to protect spaces and any special shell characters.

When a file has ACLs, the ll command displays a + after the permission string.

If a user.group matches more than one HFS ACL entry, the more specific entry takes precedence. See Example 8-2 “Multiple HFS ACL Matches”.

Example 8-1 Creating an HFS ACL

Suppose you use the chmod command to allow only yourself write permission to myfile. (This also deletes any previous HFS ACLs.)

$ chmod 644 myfile
$ ll myfile
-rw-r--r--   1 allan      users         0 Sep 21 16:56 myfile
$ lsacl myfile
(allan.%,rw-)(%.users,r--)(%.%,r--) myfile

The lsacl command displays just the default (no ACL) values, corresponding to the basic owner, group, and other permissions.

Now you use chacl to allow your manager to have read and write access to the file.

$ chacl 'naomi.users=rw' myfile
$ ll myfile
-rw-r--r--+  1 allan      users         0 Sep 21 16:56 myfile
$ lsacl myfile
(naomi.users,rw-)(allan.%,rw-)(%.users,r--)(%.%,r--) myfile

Notice two things: the ll permissions display has a + appended, indicating that ACLs exist and the ll permissions string did not change. The additional entry in the lsacl display specifies that user naomi in group users has read and write access to myfile.

Example 8-2 Multiple HFS ACL Matches

If a user’s user.group combination matches more than one ACL entry, the most specific entry takes precedence. Using file myfile,

$ chmod 644 myfile

add a write-only entry for user naomi.

$ chacl naomi.%=w myfile
$ lsacl myfile
(naomi.%,-w-)(allan.%,rw-)(%.users,r--)(%.%,r--) myfile

Now, user naomi has write access to file myfile, using the ACL defined for naomi.%, but does not have read access to the file because naomi.% takes precedence over the ACLs defined for %.users and %.%.

lsacl displays the HFS ACLs in decreasing order of specificity. That is, permission matches are attempted from left to right.

HFS ACLs and HP-UX Commands and Calls

The following commands and system calls work with ACLs on HFS file systems:
- chacl: Change HFS ACLs of files. See chacl(1).
- getaccess: List user’s access rights to files. See getaccess(1).
- lsacl: List HFS ACLs of files. See lsacl(1).
- getaccess(): Get a user’s effective access rights to a file. See getaccess(2).
- getacl(), fgetacl(): Get HFS ACL information. See getacl(2) and fgetacl(2).
- setacl(), fsetacl(): Set HFS ACL information. See setacl(2) and fsetacl(2).
- acltostr(): Convert HFS ACL structure to string form. See acltostr(3C).
- chownacl(): Change owner/group represented in an HFS file’s ACL. See chownacl(3C).
- cpacl(), fcpacl(): Copy HFS ACL and mode bits from one file to another. See cpacl(3C) and fcpacl(3C).
- setaclentry(), fsetaclentry(): Add/modify/delete an HFS file’s ACL entry. See setaclentry(3C) and fsetaclentry(3C).
- strtoacl(): Parse and convert HFS ACL structure to string form. See strtoacl(3C).
- strtoaclpatt(): Parse and convert HFS ACL pattern strings to arrays. See strtoaclpatt(3C).
ACL entries are affected by numerous HP-UX commands, system calls, and subroutine libraries — sometimes in unexpected ways.
- chmod: Deletes HFS ACLs by default. Use the -A option to retain HFS ACLs. See chmod(1).
- chmod(): Deletes HFS ACL entries. Use getacl() and setacl() to save and restore the HFS ACL entries. See chmod(2), getacl(2), and setacl(2).
- cpset: Does not set a file’s optional ACL entries. See cpset(1M).
- find: Can identify files whose ACL entries match or include specific ACL patterns on HFS or JFS file systems. See find(1).
- ls -l: The long form indicates the existence of HFS or JFS ACLs by displaying a + after the file’s permission bits. See ls(1).
- mailx: Does not support optional ACL entries on /var/mail/* files. See mailx(1).
- compact, compress, cp, ed, pack, unpack: Copy ACL entries to the new files they create. See compact(1), compress(1), cp(1), ed(1), and pack(1).
- frecover, fbackup: Use only these to selectively recover and back up files. Use the -A option when backing up from an ACL system for recovery on a system that does not support ACLs. See frecover(1M) and fbackup(1M).
- ar, cpio, ftio, shar, tar, dump, restore: These programs do not retain ACLs when archiving and restoring. They use the st_mode value returned by stat(). See ar(1), cpio(1), ftio(1), shar(1), tar(1), dump(1M), restore(1M), and stat(2).
- rcs, sccs: These packages do not support ACLs. Do not place ACL entries on system software. See rcs(1) and sccs(1).
HFS access control lists use additional “continuation inodes” when creating new file systems. Consider them when using the following programs:
- fsck: Returns the number of files with ACL entries as a value for icont. Use the -p option to clear unreferenced continuation inodes. See fsck(1M).
- diskusg, ncheck: Ignore continuation inodes. See diskusg(1M) and ncheck(1M).
- mkfs: Allows for continuation inodes on new disks. See mkfs(1M).

Using JFS Access Control Lists (ACLs)

This section describes JFS Access Control Lists and how to use them.




	NOTE: JFS supports ACLs beginning with JFS 3.3. JFS is available for HP-UX 11.0 from the HP Software Depot, http://software.hp.com and included in the operating environments for HP-UX 11i. See the HP JFS documentation on http://docs.hp.com for more information about installing JFS on HP-UX systems.




	NOTE: To use JFS ACLs you must have a VxFS file system using disk layout version 4. See vxupgrade(1M) to upgrade a file system to version 4.

Definition of a JFS ACL

A JFS ACL contains one-line entries naming specific users and groups and indicating what access is granted to each. The presence of a JFS ACL also changes the meaning of the group permission bits displayed using the ls -l command.

There are always at least four entries in a JFS ACL: a user entry, a group entry, a class entry, and an other entry. When a JFS ACL contains only these four entries, the permissions it grants are exactly the same as the permissions represented by the standard UNIX system permission bits.

While having such an ACL (we will call it a minimal JFS ACL) provides no greater functionality than the permission bits alone, we will start by describing a minimal JFS ACL, and augment it with additional entries to show how the mechanism works.

The Minimal JFS ACL

The first entry in a minimal JFS ACL indicates the permissions that the owner of the file gets, and maps directly to the owner permission bits. Because it applies to the owner of the file, no indication of the user’s name is needed. An ACL entry that grants read and write access to the file’s owner would look like this:

user::rw-

The second and third entries in a minimal ACL specify the permission granted to members of the file’s owning group; the permissions specified in these entries are exactly equal in a minimal ACL. For example, ACL entries granting read-only access to the file’s owning group would look like this:

group::r--
class:r--

The class and group entries will be described at length later in “JFS ACL Class Entries”.

The fourth and last entry in a minimal JFS ACL is a catch-all entry that specifies the permissions for anyone who isn’t granted or denied permission by any other entry. An other entry that denies access to all users not the owner of the file nor in the file’s owning group would look like this:

other:---

The minimal ACL described above would look like this in its entirety:

Example 8-3 Elements in a Minimal JFS ACL

user::rw-
group::r--
class:r--
other:---

The permission bits displayed by ls -l for this file would look like this:

rw-r-----

In the case of a minimal JFS ACL, there is a clear correspondence between the ACL entries and the permission bits.

The next section describes how additional JFS ACL entries affect file access and the interpretation of the permission bits.

Additional JFS ACL User and Group Entries

If you want to specifically grant and/or deny access to specific users and/or groups on the system, you can add up to 13 more user and group entries to the four minimal entries described in the previous section.

Additional user entries grant and deny access to specific user IDs on your system.For example, the following entry in the ACL of a file grants read, write, and execute access to a user logged in as boss:

user:boss:rwx

Similarly, additional group entries grant and deny access to specific group IDs on your system. For example, an ACL with the following entry would deny access to a user in the group spies:

group:spies:---

JFS ACL Class Entries

Class entries are distinct from owning group entries

In a file with a minimal ACL, the owning group and class ACL entries are identical. However, in a file with additional entries, the owning group and class ACL entries are distinct. The owning group entry grants permissions to a specific group: the owning group. The class entry is more general; it specifies the maximum permissions that can be granted by any of the additional user and group entries.

If a particular permission is not granted in the class entry, it cannot be granted by any ACL entries (except for the first user (owner) entry and the other entry). Any permission can be denied to a particular user or group. The class entry functions as an upper bound for file permissions.

When an ACL contains more than one group and/or user entry, the collection of additional user and group entries are referred to as the group class entries, since the effective permission granted by any of these additional entries is limited by the class entry.

Effect of chmod on class entries

When a file has a minimal ACL, the owning group and class ACL entries are identical, and chmod affects both of them. However, when a file contains additional, optional entries in the ACL:

the class ACL entry will no longer necessarily equal the owning group ACL entry
chmod affects the class ACL entry, not the owning group entry
you must use setacl to change the owning group entry

Example of JFS ACL class entries

To illustrate the function of the JFS ACL class entry, we will show how chmod and setacl affect a file with a minimal JFS ACL as well as a file with group class entries.




	NOTE: Further details about the use of the getacl and setacl commands are in “Changing the JFS Access Control List of a File with setacl”. See also getacl(1) and setacl(1).

Consider a file, exfile, with read-only (444) permissions and a minimal JFS ACL. ls -l shows the permissions for exfile as:

$ls -l exfile
-r--r--r-- 1 jsmith users 12 Sep 20 15:02 exfile

getacl lists the following output for exfile:

Example 8-4 getacl Output for exfile, a Minimal JFS ACL

$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::r--
group::r--
class:r--
other:r--

Using chmod to add write permissions to exfile changes both the owning group and the class ACL entries:

Example 8-5 getacl Output for exfile, Showing Effect of chmod

$ chmod 666 exfile
$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::rw-
group::rw-
class:rw-
other:rw-

Now we add some additional user and group entries, which will affect the class ACL entry, but not the owning group entry. The first setacl command below grants read-only permission to user guest; the other ACL entries are unaffected. However, when we grant read-execute permissions to the group dev, the upper bound on permissions (the class entry) is extended to include execute permission.

Example 8-6 getacl Output for exfile, Showing Effect of setacl

$ setacl -m u:guest:r-- exfile
$ setacl -m g:dev:r-x exfile
$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::rw-
user:guest:r--
group::rw-
group:dev:r-x
class:rwx
other:rw-

Now if we use chmod to remove write and execute permission from “group”, we actually reduce the class permissions to read-only. The owning group permissions, while unchanged, are effectively reduced to read-only as well.

Example 8-7 getacl Output for exfile, Showing Effect of chmod on Class Permissions

$ chmod g-wx exfile
$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::rw-
user:guest:r--
group::rw-	     # effective:r--
group:dev:r-x  # effective:r--
class:r--
other:rw-

Note that the other permissions are unchanged. The class entry does not limit the access that can be granted by the first user (owner) entry or the other entry.

Now ls -l will list the permissions of exfile as follows. The + at the end of the permissions string indicates that there is an ACL for the file.

Example 8-8 ls -l Output for exfile with JFS ACL

$ ls -l exfile
-rw-r--rw-+ 1 jsmith users 12 Sep 20 15:02 exfile

Default JFS Access Control Lists

Often, you will want all the files created in a directory to have certain ACL entries. For example, you might want to allow another person to write to any file in a directory of yours where the two of you are working on something together.

You can put an ACL entry granting the desired access on every file in the directory, but every time you create a new file you will have to add that entry again. Using default ACL entries, you can get the system to do this for you automatically every time a file is created.

A default ACL entry looks like this:

default:user:boss:rw-

It can be placed only on a directory, never on an ordinary file. It never has any influence on what access is granted to a user for the directory it is placed on. All it does is cause the specified entry to be included in the ACL of any file created in the directory.

If the newly created file is a directory, the default ACL entries have two effects. First, the corresponding non-default ACL entries are created, so that the desired permissions are granted and denied for the directory, just as for any file created in the directory. Second, the default entries themselves are copied, so that the new subdirectory has the same default ACL as the parent directory.

For example, if you want any files created in the directory projectdir to be readable by certain users, you could create the appropriate default entries as shown below.

Example 8-9 A JFS ACL with Default Entries

$ getacl projectdir
# file: projectdir
# owner: jsmith
# group: users
user::rw-
user:boss:rw-
user:jjones:rw-
user:jdoe:---
group::rw-
group:dev:rw-
class:rw-
other:---
default:user:boss:r---
default:user:jjones:r--
default:group:dev:r--

With these entries in place, any new file created in the directory projectdir could have an ACL like that shown below for planfile. The entries for user:boss, user:jjones, and group:dev are generated from the default entries on the projectdir directory.

Example 8-10 Effect of Default Entries on a New File

$ getacl planfile
# file: planfile
# owner: jsmith
# group: users
user::rw-
user:boss:r--
user:jjones:r--
group::rw-
group:dev:r--
class:rw-
other:---

If the newly created file is a directory, the same ACL entries are generated, but in addition the default entries themselves are also placed in the ACL, as shown in docdir, below.

Example 8-11 Effect of Default Entries on a New Directory

$ getacl docdir
# file: docdir
# owner: jsmith
# group: users
user::rw-
user:boss:r--
user:jjones:r--
group::rw-
group:dev:r--
class:rw-
other:---
default:user:boss:r--
default:user:jjones:r--
default:group:dev:r--

How the System Generates a JFS ACL

Whenever a file is created on a VxFS version 4 file system, the system initializes a minimal JFS ACL for the file, containing a user entry for the owner permissions, a group entry for the owning group permissions, a class entry for the owning group permissions, and an other entry for the other group permissions. Additional entries may be added by the user, or as a result of default entries specified on the parent directory.

Examining a JFS ACL with getacl

The getacl command reports the entries in the ACL. As indicated, each ACL has at least four entries, one each corresponding to the file mode permissions for owner, group, class, and other.

File permission bits for user and group are translated into special cases of these entries:

The bits representing owner permissions are represented by a user entry without a specified user ID.
The bits representing group permissions are represented by a group entry without a specified group ID.

In an ACL, there must be one each of these special user and group entries. There may be any number of additional user entries and group entries, but these must all contain a user ID or group ID, respectively. There is only one other entry in an ACL, representing the permission bits for permissions to be granted to other users.

The following is an example of the output of the getacl command for a file named junk owned by user1 in group1 whose permission mode bits are -rw-rw-r--:

Example 8-12 Example getacl Output for a Minimal JFS ACL

$ getacl junk
# file: junk
# owner: user1
# group: group1
user::rw-
group::rw-
class:rw-
other:r--

If setacl is used to give read-write permission to user2 and user3 and read-only permission to group2, getacl would produce the following output:

Example 8-13 Example getacl Output after Additions to the ACL

$ getacl junk
# file: junk
# owner: user1
# group: group1
user::rw-
user:user2:rw-
user:user3:rw-
group::rw-
group:group2:rwx
class:rwx
other:r--

Note that the class entry changed to include execute permission when the group2 entry was given execute permission.

getacl shows effective permissions when they are more restricted than the permissions that specifically granted in the ACL. For example, if we use chmod to deny execute permissions to the group class, some ACL entries will show an #effective permission that differs from the ACL entry:

Example 8-14 Example getacl Output Showing Effective Permissions

$ chmod g-x junk
$ getacl junk
# file: junk
# owner: user1
# group: group1
user::rw-
user:user2:rw-
user:user3:rw-
group::rw-
group:group2:rwx  #effective:rw-
class:rw-
other:r--

Because chmod affects the class ACL entry and not the owning group entry, chmod may be used to deny access to all additional user and group entries without the need to reset each entry with setacl.

Changing the JFS Access Control List of a File with setacl

If you are user1 (the owner of the file junk used in examples earlier in this section), you can provide read access for junk to an additional user by adding an entry to the ACL naming that user and specifying read access. You do this with the setacl command.

Using setacl -m

For example, the following command gives user boss read-only access to the file:

setacl -m u:boss:r-- junk

The -m (modify) option indicates that you are adding or changing an entry to the ACL.

You can add group-specific entries in just the same way. For example, to grant read and write access to everyone in the group dev, type the following:

setacl -m g:dev:rw- junk

The -m option can be used to change an existing entry as well as add a new one. If an entry already exists for the specified user or group, the permissions for that entry are set to the values specified on the command line.

Using setacl -d

The -d option deletes an entry. With -d, you do not specify any permissions in the ACL entry. For example, the following command deletes the entry for the group dev:

setacl -d g:dev junk

Adding or changing multiple entries with setacl

You may add, change, or delete any number of entries on the same command line with the -m and -d options. You can either supply a comma-separated list of entries to an option, or repeat the option with additional entries. For example the following two command lines have the same effect:

setacl -m u:user4:---,u:user5:r-- junk
setacl -m u:user4:--- -m u:user5:r-- junk

You can also combine the -m and -d options on the same command line.

Using setacl -f

If you are adding or changing several entries, you will probably want to use a different procedure. You can save the ACL to a file, edit it, adding, changing, or deleting entries to produce whatever ACL you want, and then apply this new ACL to the file. For example, you could save the ACL to a file with this command:

getacl junk > junk.acl

Then you could edit it so that it appeared as below.

Example 8-15 A Complex JFS ACL

$ cat junk.acl
# file: junk
# owner: user1
# group: group1
user::rw-
user:user2:rw-
user:user3:rw-
user:user4:---
user:user5:r--
group::rw-
group:group2:rw-
group:group3:r--
group:group4:---
group:group5:rw-
class:rw-
other:r--

This ACL can now be applied to the file by using the -f option of the setacl command as follows:

setacl -f junk.acl junk

In this example, several changes have been made. While before the ACL entries only granted access to people, now they are used to deny access as well. Note specifically the entries for user user4 and group group4.

Effective Permissions and setacl -n

Normally, setacl recalculates the class entry so as to ensure that permissions granted in the additional ACL entries will actually be granted.If the -n option is specified, the class entry is not recalculated; the existing value is used. This means that some permissions granted by the ACL entries will not be granted in practice. For example, returning to our exfile example, when it was a minimal ACL with read-write permissions across the board:

$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::rw-
group::rw-
class:rw-
other:rw-

Suppose we use setacl -n to add read-execute permissions to group dev as follows:

Example 8-16 Effect of setacl -n, Showing Effective Permissions

$ setacl -n -m group:dev:r-x exfile
$ getacl exfile
# file: exfile
# owner: jsmith
# group: users
user::rw-
group::rw-
group:dev:r-x     #effective r--
class:rw-
other:rw-

The group dev ACL entry is added as specified, but execute permission will not actually be granted. Execute permission is denied by the class entry, and the class entry was not recalculated because -n was specified. If -n was not used, class would have been reset to class:rwx, and the effective comment would not be there.

Comparison of JFS and HFS ACLs

JFS ACLs adhere to the POSIX ACL standard.

JFS ACLs differ from HFS ACLs in both format (internal and external) and functionality.

Functional Differences Between JFS and HFS ACLs

Functional differences between JFS and HFS ACLs include:

A JFS directory’s ACL can have default entries, which are applied to files subsequently created in that directory. HFS ACLs do not have this capability.
An HFS ACL has an owner that can be different from the owner of the file the ACL controls. JFS ACLs are owned by the owner of the corresponding file.
An HFS ACL can have different entries for a particular user in specific groups. For example, userx may have read and write access while a member of group users, but have only read access while a member of group other.

JFS and HFS Command and Function Mapping

The following table lists equivalent commands and functions for JFS ACLs and HFS ACLs.

Table 8-1 HFS and JFS ACL Equivalents

HFS Name	JFS Equivalent
chacl(1)	setacl(1)
`lsacl`(1)	getacl(1)
getacl(2)	acl(2)
fgetacl(2)	—none—
setacl(2)	acl(2)
fsetacl(2)	—none—
acltostr(3C)	—none—
chownacl(3C)	—none—
cpacl(3C)	—none—
setaclentry(3C)	—none—
strtoacl(3C)	—none—
—none—	aclsort(3C)
acl(5)	aclv(5)

ACLs in a Network Environment

ACLs are not visible on remote files by Network File System (NFS), although their control over access permissions remains effective. Individual manpage entries specify the behavior of the various system calls, library calls, and commands under these circumstances. Use caution when transferring a file with optional entries over a network, or when manipulating a remote file, because optional entries are deleted with no indication.

Setting Default Permissions

The default umask setting in a standard system is octal 000. This should be changed to u=rwx,g=rx,o=rx (or octal 022). This means that all directories created will have a default permission mode of 755, granting access of drwxr-xr-x. All files created will have the default permission mode of 644, granting access of -rw-r--r--. See umask(1).

Protecting Directories

If a directory is writable in a category (either through standard permissions or ACLs), anyone in that category can remove its files, regardless of the permissions on the files themselves. There are two ways to protect against unwanted deletions:

Remove write permissions for categories that should not have them.
This is particularly effective for users’ private directories. The command
chmod 755 mydir
allows others to read and search the mydir directory but only the owner can delete files from it.
Set the sticky bit on the directory. This allows only the owner of the file, the owner of the directory, and the superuser to delete the file.
This is effective for temporary or project directories (such as /tmp and /var/tmp) that must be accessible to many authorized users. The command
chmod a+rwxt /mfgproj
allows anyone to create, read, and write files in /mfgproj, but only the file owner, the directory owner, or root can delete files.

Protecting User Accounts

These guidelines should be followed to protect user accounts:

Except for the owners, home directories should not be writable because it allows any user to add and remove files from them.
Users’ .profile, .kshrc, .login, and .cshrc files should not be writable by anyone other than the account owner.
A user’s .rhosts file should not be readable or writable by anybody other than the owner. This precaution prevents users from guessing what other accounts you have, as well as preventing anyone from editing your .rhosts file to gain access to those systems. See hosts.equiv(4).
Use of a .netrc file is discouraged, since it bypasses login authentication for remote login and even contains the user’s unencrypted password. If used, .netrc must not be readable or writable by anyone other than its owner. See netrc(4).
Some systems maintain an /etc/securetty file, which should not be writable. See login(1).

Security Considerations for Device Files

Access to all devices in your system is controlled by device special files, which enable programs to be device independent. These files have been shipped with permission settings that enable proper use and maximal security.

If you install any other special files, refer to insf(1M) for the correct permission settings.

Since device special files can be as vulnerable to tampering as any other file, observe the following precautions:

All device files should be kept in /dev.
Protect the memory files, /dev/mem and /dev/kmem, from casual access, since these files contain sensitive user information. For example, a program that watches memory for an invocation of the login program might copy the password from login’s buffers when a user types it in. The directory entries should look like:
```
crw-r-----   1 bin        sys          3 0x000001 Jun  9  1996 /dev/kmem
crw-r-----   1 bin        sys          3 0x000000 Jun  9  1996 /dev/mem
```

Protect all disk special files:

Write-protect all disk special files from general users, to prevent inadvertent data corruption. Turn off write access for group and other.
Read-protect disk special files to prevent disclosure. Turn off read access for other.

The directory entries should look like:

brw-r-----   1 bin        sys         31 0x002000 Feb 18  1998 /dev/dsk/c0t2d0
crw-r-----   1 bin        sys        188 0x002000 Aug  3  1998 /dev/rdsk/c0t2d0
brw-r-----   1 root       sys         64 0x000002 Jun 11  1996 /dev/vg00/lvol2
crw-r-----   1 root       sys         64 0x000002 Jun 11  1996 /dev/vg00/rlvol2

Terminal ports on UNIX systems may be writable by anyone, if you are allowing users to communicate by using the write or talk programs. Only the owner, however, should have read permission.
Individual users should never own a device file other than a terminal device or personal printer.
Before putting a disk or other mountable device of unknown origin into service, check its files for special files and setuid programs. See “Guidelines for Mounting and Unmounting a File System”.

Protecting Disk Partitions and Logical Volumes

The device files for disk partitions and logical volumes should be readable only by root and perhaps by an account used for disk backups. See “Security Considerations for Device Files”.
Since ownership and permissions are stored in the inode, anyone with write permission to a mounted partition can set the user ID for any file in that partition, regardless of the owner, bypassing the chmod() system call and other security checks.
If a program, such as a database, requires direct access to the partition, that partition should be reserved exclusively for the program and never mounted. Program users should be informed that the file’s security is enforced by its permission settings, rather than by the UNIX file system.