Managing Access to Files and Directories

Using ACLs, chacl, and lsacl

In a traditional HP-UX system, you use the ls -l command to see a full listing of a file's permissions and ls -ld to list a directory's permissions. The chmod(1) command lets you change the permissions of directories and files.

You can additionally use access control lists (ACLs) to extend the traditional permission mechanism by giving users greater degree of selectivity for access control. Access permissions and restrictions may be specified to the granularity of specific users and groups.

chacl(1) creates and changes ACLs and lsacl(1) lists the ACLs of files.

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. For example, suppose you use the chmod command to allow only yourself write permission to myfile. You can use the chacl command to make an exception and allow your manager write permission to myfile also.

Use chmod with the -A option when working with files that have additional permissions assigned. The additional permissions will be deleted if you fail to use the -A option with chmod. Example:

chmod -A mode filename

The general form for the chacl command is as follows:

$ chacl 'user.group operator mode' file_name

where: user and group indicate the user's login name and group; a percent sign (%) means all users or groups. The operator indicates adding (+) or denying (-) permissions and an equals sign (=) means "this permission exactly." The mode indicates the permissions allowed: read (r), write (w), and execute/search (x). An operator immediately precedes the mode (for example, +rw adds read and write permissions; -rw denies read and write permissions).

$ chacl 'carolyn.users=rw' myfile

$ ll myfile

-rw-r-----+ 1 nora users 236 Mar 8 14:23 myfile

$ lsacl myfile

(carolyn,users,rw-) (nora.%,rwx) (%.users,r--)(%.%,---) myfile

The plus sign (+) sign at the end of the permission string as displayed by ll means that additional permissions (in the form of optional ACL entries) exist for myfile.

More specific entries that match take precedence over any less specific matches.




	NOTE: ACLs are not supported under VxFS.

Setting Default Permissions

The default umask setting in a trusted system should be set 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--.

If a directory is writable, anyone can remove its files, regardless of the permissions on the files themselves. The only way to ensure that no files can be removed from a directory is to remove write permission from that directory.

Protecting User Accounts

These guidelines should be followed to protect user accounts:

Except for the owners, home directories should not be writable because it allow any user to add and remove files from them.
Users' .profile, .cshrc, and .login 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.
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.
Some systems maintain an /etc/securetty file, which should not be writable.

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:

Protect the memory and swap files, mem, kmem, and swap, 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.
All device files should be kept in /dev.
Write-protect all disk special files from general users, to prevent inadvertent data corruption.
Read-protect disk special files to prevent disclosure.
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 mounting a disk or other mountable device of unknown origin, first check its files for special files and setuid programs.

Protecting Disk Partitions

Disk partitions should be readable only by root.
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.

ACLs and HP-UX Commands and Calls

The following commands and calls work with ACLs:

chacl(1) - change ACLs of files.
getaccess(1) - list access rights to files.
lsacl(1) - list access control lists of files.
getaccess(2) - get a user's effective access rights to a file.
getacl, fgetacl(2) - get access control list information.
setacl, fsetacl(2) - set access control list information.
acltostr(3C) - convert ACL structure to string form.
chownacl(3C) - change owner/group represented in a file's ACL.
cpacl(3C), fcpacl(3C) - copy ACL and mode bits from one file to another.
setaclentry(3C), fsetaclentry(3C) - add/modify/delete a file's ACL entry.
strtoacl(3C) - parse and convert ACL structure to string form.
strtoaclpatt(3C) - parse and convert ACL pattern strings to arrays.

Optional ACL entries are affected by numerous HP-UX commands, system calls, and subroutine libraries — sometimes in unexpected ways.

chmod(1) - use the -A option to retain ACLs.
chmod(2) - optional ACL entries are deleted when chmod() is used. Use getacl and setacl to save and restore the ACL entries.
cpset(1) - cpset does not set a file's optional ACL entries.
find(1) - new functionality enables find to identify files whose ACL entries match or include specific ACL patterns.
ls(1) - in long form, ls indicates the existence of ACLs by displaying a + after the file's permission bits.
mailx(1) - mailx does not support optional ACL entries on /usr/mail/* files.
compact(1) compress(1) cp(1) ed(1) makecdf(1) pack(1) unpack(1) - these programs copy optional ACL entries to the new files they create.
frecover(1M), fbackup(1M) - use only these to selectively recover and back up files. Use the -A option when backing up and recovering files on systems that do not implement ACLs.
ar(1), cpio(1), ftio(1), shar(1), tar(1), dump(1M), restore(1M) - these programs do not retain ACLs when archiving and restoring. They use the st_mode value returned by stat().
SCCS, RCS - the commands in these packages do not support ACLs. Do not place optional ACL entries on system software.

Access control lists use additional, "continuation inodes" when creating new file systems. Consider them when using the following programs:

fsck(1M) - fsck returns the number of files with optional ACL entries as a value for icont. Use the -p option to clear unreferenced continuation inodes.
diskusg(1M), ncheck(1M) - these commands ignore continuation inodes.
mkfs(1M) - allow for continuation inodes on new disks.

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 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.