6-System Data Files and Information

Please indicate the source: http://blog.csdn.net/gaoxiangnumber1

Welcome to my github: https://github.com/gaoxiangnumber1

6.1 Introduction

6.2 Password File

• UNIX password file, called the user database by POSIX.1, contains the fields shown in Figure 6.1. These fields are contained in a passwd structure that is defined in

root:x:0:0:root:/root:/bin/bash
squid:x:23:23::/var/spool/squid:/dev/null
nobody:x:65534:65534:Nobody:/home:/bin/sh
sar:x:205:105:Stephen Rago:/home/sar:/bin/bash

• There is an entry with the user name root that has a user ID of 0(the superuser).
• The encrypted password field contains a single character as a placeholder where UNIX used to store the encrypted password.
• Some fields in a password file entry can be empty. If the encrypted password field is empty, it usually means that the user does not have a password.
• The shell field contains the name of the executable program to be used as the login shell for the user. The default value for an empty shell field is usually /bin/sh. Note the entry for squid has /dev/null as the login shell. This is a device and cannot be executed, so prevent anyone from logging in to our system as user squid.
• There are several alternatives to using /dev/null to prevent a user from logging in to a system. For example, /bin/false is often used as the login shell. It exits with an unsuccessful(nonzero) status; the shell evaluates the exit status as false. We use /bin/true to disable an account; it exits with a successful(zero) status. Some systems provide the nologin command, which prints a customizable error message and exits with a nonzero exit status.
• The nobody user name can be used to allow people to log in to a system, but with a user ID(65534) and group ID(65534) that provide no privileges. The only files that this user ID and group ID can access are those that are readable or writable by the world.
• Systems that provide the finger(1) command support additional information in the comment field. Each of these fields is separated by a comma: the user’s name, office location, office phone number, and home phone number. An ampersand in the comment field is replaced with the login name(capitalized) by some utilities. For example:
  sar:x:205:105:Steve Rago, SF 5-121, 555-1111, 555-2222:/home/sar:/bin/sh
• Even system doesn’t support the finger command, these fields can still go into the comment field, since that field is simply a comment and not interpreted by system utilities.
• Linux provide the vipw command to allow administrators to edit the password file. The vipw command serializes changes to the password file and makes sure that any additional files are consistent with the changes made.
• POSIX.1 defines two functions to fetch entries from the password file. These functions allow us to look up an entry given a user’s login name or numerical user ID.

#include <sys/types.h>
#include <pwd.h>
struct passwd *getpwuid(uid_t uid);
struct passwd *getpwnam(const char *name);
Both return: pointer if OK, NULL on error

• getpwuid is used by the ls(1) program to map the numerical user ID contained in an i-node into a user’s login name.
• getpwnam is used by the login(1) program when we enter our login name.
• Both functions return a pointer to a passwd structure that the functions fill in. This structure is usually a static variable within the function, so its contents are overwritten each time we call either of these functions.
• Three functions can be used go through the entire password file: getpwent, setpwent, and endpwent.

#include <pwd.h>
struct passwd *getpwent(void);
Returns: pointer if OK, NULL on error or end of file
void setpwent(void);
void endpwent(void);

• We call getpwent to return the next entry in the password file and getpwent returns a pointer to a structure that it has filled in. This structure is normally overwritten each time we call this function. If this is the first call to this function, it opens whatever files it uses. There is no order implied when we use this function; the entries can be in any order, because some systems use a hashed version of the file /etc/passwd.
• setpwent rewinds whatever files it uses, and endpwent closes these files. When using getpwent, we must always be sure to close these files by calling endpwent when we’re through.
• Figure 6.2 shows an implementation of the function getpwnam.

• The call to setpwent at the beginning of this function is self-defense: we ensure that the files are rewound, in case the caller has already opened them by calling getpwent.
• We call endpwent when we’re done, because neither getpwnam nor getpwuid should leave any of the files open.

6.3 Shadow Passwords

• The encrypted password is a copy of the user’s password that has been put through a one-way encryption algorithm. Because this algorithm is one-way, we can’t guess the original password from the encrypted version.
• When we place a single character in the encrypted password field, we ensure that an encrypted password will never match this value.
• To make it more difficult to obtain the encrypted passwords, systems store the encrypted password in the shadow password file. This file has to contain the user name and the encrypted password. Other information relating to the password is also stored here(Figure 6.3).

• The only two mandatory fields are the user’s login name and encrypted password. The other fields control how often the password is to change(known as ‘‘password aging’’) and how long an account is allowed to remain active.
• Only a few programs need to access encrypted passwords(E.g.: login(1), passwd(1)) and these programs are often set-user-ID root.
• On Linux, separate functions is available to access the shadow password file.

#include <shadow.h>
struct spwd *getspnam(const char *name);
struct spwd *getspent(void);
Both return: pointer if OK, NULL on error
void setspent(void);
void endspent(void);

6.4 Group File

• UNIX group file, called the group database by POSIX.1, contains the fields shown in Figure 6.4. These fields are contained in a group structure that is defined in

#include <grp.h>
struct group *getgrgid(gid_t gid);
struct group *getgrnam(const char *name);
Both return: pointer if OK, NULL on error

• Both return pointers to a static variable, which is overwritten on each call.
• If we want to search the entire group file, we need the following three functions.

#include <grp.h>
struct group *getgrent(void);
Returns: pointer if OK, NULL on error or end of file
void setgrent(void);
void endgrent(void);

• setgrent opens the group file, if it’s not already open, and rewinds it.
• getgrent reads the next entry from the group file, opening the file first, if it’s not already open.
• endgrent closes the group file.

6.5 Supplementary Group IDs

• Supplementary group IDs: Not only did we belong to the group corresponding to the group ID in our password file entry, but we could also belong to as many as 16 additional groups. In addition to comparing the the file’s group ID to the process effective group ID, it was also compared to all the supplementary group IDs.
• Advantage: We no longer have to change groups explicitly.

#include <unistd.h>
int getgroups(int gidsetsize, gid_t grouplist[]);
Returns: number of supplementary group IDs if OK, −1 on error
#include <grp.h>
int setgroups(int ngroups, const gid_t grouplist[]);
#include <grp.h>
int initgroups(const char *username, gid_t basegid);
Both return: 0 if OK, −1 on error

• getgroups fills in the array grouplist with the supplementary group IDs. Up to gidsetsize elements are stored in the array. The number of supplementary group IDs stored in the array is returned by the function. If gidsetsize is 0, the function returns only the number of supplementary group IDs. The array grouplist is not modified. This allows the caller to determine the size of the grouplist array to allocate.
• setgroups can be called by the superuser to set the supplementary group ID list for the calling process: grouplist contains the array of group IDs, and ngroups specifies the number of elements in the array. The value of ngroups cannot be larger than NGROUPS_MAX.
• setgroups is usually called from initgroups, which reads the entire group file and determines the group membership for username. It then calls setgroups to initialize the supplementary group ID list for the user. One must be superuser to call initgroups, since it calls setgroups. In addition to finding all the groups that username is a member of in the group file, initgroups includes basegid in the supplementary group ID list; basegid is the group ID from the password file for username.
• The initgroups function is called by only a few programs. The login(1) program, for example, calls it when we log in.

6.6 Implementation Differences

• On many systems, the user and group databases are implemented using the Network Information Service (NIS). This allows administrators to edit a master copy of the databases and distribute them automatically to all servers in an organization. Client systems contact servers to look up information about users and groups. NIS+ and the Lightweight Directory Access Protocol (LDAP) provide similar functionality. Many systems control the method used to administer each type of information through the /etc/nsswitch.conf configuration file.

6.7 Other Data Files

• The general principle is that every data file has at least three functions:
  
  1. A get function that reads the next record, opening the file if necessary. These functions normally return a pointer to a structure. A null pointer is returned when the end of file is reached. Most of the get functions return a pointer to a static structure, so we always have to copy the structure if we want to save it.
  2. A set function that opens the file, if not already open, and rewinds the file. We use this function when we know we want to start again at the beginning of the file.
  3. An end entry that closes the data file. We always have to call this function when we’re done, to close all the files.
• If the data file supports some form of keyed lookup, routines are provided to search for a record with a specific key. For example, two keyed lookup routines are provided for the password file: getpwnam looks for a record with a specific user name, and getpwuid looks for a record with a specific user ID.

• In figure 6.6, we show the functions for the password files and group file and some of the networking functions. There are get, set, and end functions for all the data files in this figure.

6.8 Login Accounting

• The utmp file keeps track of all the users currently logged in, and the wtmp file keeps track of all logins and logouts. With Version 7, one type of record was written to both files, a binary record consisting of the following structure:

struct utmp
{
    char ut_line[8];        /* tty line: "ttyh0", "ttyd0", "ttyp0", ... */
    char ut_name[8];        /* login name */
    long ut_time;       /* seconds since Epoch */
};

• On login, one of these structures was filled in and written to the utmp file by the login program, and the same structure was appended to the wtmp file.
• On logout, the entry in the utmp file was erased(filled with null bytes) by the init process, and a new entry was appended to the wtmp file. This logout entry in the wtmp file had the ut_name field zeroed out.
• Special entries were appended to the wtmp file to indicate when the system was rebooted and right before and after the system’s time and date was changed. The who(1) program read the utmp file and printed its contents in a readable form.
• On Linux, the utmp(5) manual page gives the format of their versions of these login records. The pathnames of these two files are /var/run/utmp and /var/log/wtmp.

6.9 System Identification

• POSIX.1 defines the uname function to return information on the current host and operating system.

#include <sys/utsname.h>
int uname(struct utsname *name);
Returns: non-negative value if OK, −1 on error

• We pass the address of a utsname structure to this function, and the function then fills it in.

struct utsname
{
    char sysname[];     // name of the operating system
    char nodename[];    // name of this node
    char release[];     // current release of operating system
    char version[];     // current version of this release
    char machine[];     // name of hardware type
};

• Each string is null terminated. The maximum name lengths, including the terminating null byte, are listed in Figure 6.7.

• The information in the utsname structure can usually be printed with the uname(1) command.
• POSIX.1 warns that the nodename element may not be adequate to reference the host on a communications network.
• BSD-derived systems provided the gethostname function to return only the name of the host. This name is usually the name of the host on a TCP/IP network.

#include <unistd.h>
int gethostname(char *name, int namelen);
Returns: 0 if OK, −1 on error

• The namelen argument specifies the size of the name buffer. If enough space is provided, the string returned through name is null terminated. If insufficient room is provided, it is unspecified whether the string is null terminated.
• gethostname specifies that the maximum host name length is HOST_NAME_MAX. Figure 6.7 summarizes the maximum name lengths.
• If the host is connected to a TCP/IP network, the host name is normally the fully qualified domain name of the host.
• There is a hostname(1) command that can fetch or set the host name. The host name is set by the superuser using sethostname function. The host name is normally set at bootstrap time from one of the start-up files invoked by /etc/rc or init.

6.10 Time and Date Routines

6.11 Summary

Please indicate the source: http://blog.csdn.net/gaoxiangnumber1

Welcome to my github: https://github.com/gaoxiangnumber1