Classic Shell Scripting - Arnold Robbins [239]
The ulimit built-in shell command controls system resource limits. The -a option prints the value of all resources. On our systems, we get this result concerning file sizes:
$ ulimit -a
Show the current user process limits
...
file size (blocks) unlimited
...
Your system might be different because of local management policies.
At some Unix sites, disk quotas are enabled (see the manual pages for quota(1) for details), putting further limits on the total amount of filesystem space that a single user can occupy.
* * *
[19] GB = gigabyte, approximately 1 billion (one thousand million) bytes. Despite the metric prefix, in computer use G usually means 230 = 1,073,741,824.
Unix File Attributes
Earlier in this Appendix, in Section B.4.3, we described the Unix filesystem implementation, and said that the inode entries contain metadata: information about the file, apart from its name. It is now time to discuss some of these attributes because they can be highly relevant to users of the filesystem.
File Ownership and Permissions
Perhaps the biggest difference from single-user personal-computer filesystems is that Unix files have ownership and permissions.
Ownership
On many personal computers, any process or user can read or overwrite any file, and the term computer virus is now familiar to readers of almost any daily newspaper, even if those readers have never used a computer themselves. Because Unix users have restricted access to the filesystem, it is much harder to replace or destroy critical filesystem components: viruses are seldom a problem on Unix systems.
Unix files have two kinds of ownership: user and group, each with its own permissions. Normally, the owner of a file should have full access to it, whereas members of a work group to which the owner belongs might have limited access, and everyone else, even less access. This last category is called other in Unix documentation. File ownership is shown by the verbose forms of the ls command.
New files normally inherit owner and group membership from their creator, but with suitable permissions usually given only to system managers, the chown and chgrp commands can be used to change those attributes.
In the inode entry, the user and group are identified by numbers, not names. Since humans generally prefer names, system managers provide mapping tables, historically called the password file , /etc/passwd, and the group file, /etc/group. At large sites, these files are generally replaced by some sort of network-distributed database. These files, or databases, are readable by any logged-in user, although the preferred access is now via library calls to setpwent( ), getpwent( ), and endpwent( ) for the password database, and setgrent( ), getgrent( ), and endgrent( ) for the group database: see the manual pages for getpwent(3) and getgrent(3). If your site uses databases instead of files in /etc, try the shell command ypcat passwd to examine the password database, or ypmatch jones passwd to find just the entry for user jones. If your site uses NIS+ instead of NIS, the yp commands become niscat passwd.org_dir and nismatch name=jones passwd.org_dir.
The important point is that it is the numeric values of the user and group identifiers that control access. If a filesystem with user smith attached to user ID 100 were mounted on, or imported to, a filesystem with user ID 100 assigned to user jones, then jones would have full access to smith's files. This would be true even if another user named smith exists on the target system. Such considerations can become important as large organizations move toward globally accessible Unix filesystems: it becomes essential to have organization-wide agreement on the assignment of user and group identifiers. This is not as simple as it appears: not only are there turf wars, but there are severe limitations on the number of distinct user and group identifiers. Older Unix systems allocated