solaris operating environment boot campptgmedia.pearsoncmg.com/imprint_downloads/informit/... ·...

Solaris ™

OperatingEnvironment

Boot Camp

David RhodesDominic Butler

Sun Microsystems Press • A Prentice Hall Title

1-title.fm Tuesday, August 6, 2002 11:12 AM

v

TABLE OFCONTENTS

Introduction xxvii

1 The System Administrator’s Role 1The Importance of a System Administrator 1

Who Is the System Administrator? 3Role Based Access Control 4Who’s Been Logging In? 4Checking the Sulog 5Automating the Check 6

2 Booting and Halt ing the System 7Objectives 8

Switching On 8

The Boot Process 8Run Levels 10RC Scripts 13

2-TOC.fm Page v Tuesday, August 6, 2002 11:12 AM

vi Table of Contents

Solaris Processes 17Killing Processes 24Trapping Signals 27Additional Process Management Tools 28Defunct Processes 28

Switching Off 29

The OpenBoot PROM 31

3 User Administrat ion 37Objectives 38

What Are Users? 38

What Are Groups? 39

UIDs and GIDs 39

Password File 40Field 1: Login Name 40Field 2: Password 41Field 3: User ID Number 41Field 4: Group ID Number 41Field 5: Comment Field 42Field 6: The Home Directory 42Field 7: The Program to Run on Login 42

Shadow File 43Field 1: Login Name 43Field 2: Encrypted Password 43Field 3: Password Change Date 44Field 4: Minimum Change Days 44Field 5: Maximum Valid Days 44Field 6: Number of Warning Days 44Field 7: Number of Inactive Days 44

2-TOC.fm Page vi Tuesday, August 6, 2002 11:12 AM

Table of Contents vii

Field 8: Expiry Date 44Field 9: Not Used 44

Group File 45Field 1: Group Name 45Field 2: Group Password 45Field 3: Group Identity Number 46Field 4: Group User List 46

Primary and Secondary Groups 46

The Implementation 48Our “Company Standards” 49Adding a Test User with Groupadd and Useradd 50Setting the Password 51Testing the Account 52Modifying with Usermod 52Removing the User 53Useradd Defaults 54Manually Updating the System Files 55Real and Effective IDs 57

Using RBAC 57How It Works 58Authorizations 58Profiles 59Roles 61Create the System Administrator Role 62

Creating a Custom Script 64

Checking the Files 66Pwconv 66Pwck and Grpck 67Passwd 67

Conclusion 68

2-TOC.fm Page vii Tuesday, August 6, 2002 11:12 AM

viii Table of Contents

4 Permissions and Al l That 69Objectives 69

Why Do We Need Permissions? 70

How Permissions Are Represented 70

Setting Permissions 71Default Permissions 74File Ownership 74Sticky Bits 76

Access Control Lists 84

The Implementation 90

Octal Permissions Lookup Table 91

5 Shel ls 93Objectives 93

What Is a Shell? 94

What Shells? C Shells? 95

Shell Variables 97Using Shell Variables 97Using Variables in Shell Scripts 98Positional Parameters 99Scope of Shell Variables 101The Environment 101

Assigning Shells to Users 105

Running Commands 107

Wildcards 110Additional Notes on Wildcards 113

Hiding Things from the Shell 114

2-TOC.fm Page viii Tuesday, August 6, 2002 11:12 AM

Table of Contents ix

Command Substitution 117

Shortcuts 118Home Directory 118Previous Directory 118Aliases 118

What Else Does the Shell Do? 119File Redirection 119Pipelines 123And the Rest 124

Shell Start-Up Files 126

The Implementation 127/Etc/profile 127Root User’s .profile 129Other Users’ .profile 129

Example Shell Scripts 129

6 The Fi lesystem and Its Contents 133Objectives 134

What Is a Filesystem? 134

Why Do We Use Filesystems? 139

Preparing the Disk to Receive Filesystems 139

What Type of Filesystem Should We Use? 144System V Filesystem Type 146UFS Type 147TMPFS Type 150PROCFS Type 151File Descriptor Filesystem (FDFS) Type 151

Creating and Removing Filesystems 151Checking and Repairing Filesystems 155

2-TOC.fm Page ix Tuesday, August 6, 2002 11:12 AM

x Table of Contents

Lost+found Directories 156

Files and Directories 157Devices 163Solaris Directories 163

Log Files 165

The Implementation 167Housekeeping the Log Files 167Checking Filesystem Usage 170

7 Swap Space 173Objectives 173

Swapping and Paging 174Paging 174Swapping 175Which Is Best? 175Is Swap Really Needed? 176

The Scheduler 176

How Big Should It Be? 177The 2 GB Swap Limit 178

Swap Locations 179Raw Disk Partitions 179Swap Files 180Adding the Swap Devices 181

Monitoring Swap Space 183Using Sar 184Using Vmstat 185

2-TOC.fm Page x Tuesday, August 6, 2002 11:12 AM

Table of Contents xi

8 Administer ing Packages 187Objectives 188

What Is a Package? 188

Using Packages 188

What Packages Have I Got Loaded? 188

Adding, Removing, and Checking Packages 191Adding Packages 191Removing Packages 195Checking Packages 197

Dissecting a Package 199Pkginfo 200Pkgmap 202Reloc 204Install 205Archive 206

Advanced Concepts 207

Creating Your Own Packages 211

9 Patching the System 217Objectives 218

What Are Patches? 218Recommended Patches 218Kernel Patches 219Security Patches 219Public Patches 219Maintenance Updates 219

Files and Their Locations 220Progressive versus Direct Instance Patching 220

2-TOC.fm Page xi Tuesday, August 6, 2002 11:12 AM

xii Table of Contents

/Var/sadm/patch 220/Var/sadm/pkg 221Disk Space 222

Determining What’s Installed 222Detecting Patches 222

Adding Patches 225Removing Old Revisions 226Installing Recommended Patches 227Adding Individual Patches 230Loading Multiple Patches 231

Obsolete Patches 232

Removing Patches 233

Checking the System 234

10 Administer ing Quotas 235Objectives 235

What Are Quotas? 236

Enabling Quotas 236

Configuring the User’s Quotas 238

Checking the Limits 239

Setting Default User Quotas 241

Disabling User Quotas 241

Automatically Checking the Limits 242The Crontab Entry 244

Should We Use Them? 244

2-TOC.fm Page xii Tuesday, August 6, 2002 11:12 AM

Table of Contents xiii

11 Connecting to the Local Area Network 247Objectives 248

Description 248

IP Addressing Schemes 249Class-Based 249Subnetting 250CIDR 252Unicast, Multicast, and Broadcast Addresses 254Illegal Addresses 254

Choosing an IP Address 255Reserved Addresses 256

Our Values 256

Naming Systems 258

Host Names 258

Loopback Interface 259

Initial Network Testing 260

Configuring the Interface 260Dynamic Configuration 261Permanent Changes 262The Rest of the Subnet 262

Routing 264

Connecting the Second Subnet 264

Adding the Gateway 265

Routing—A Second Look 268Disabling Router Discovery 269Manually Adding Static Routes 270

Address Resolution 271Determining the MAC Address 272

2-TOC.fm Page xiii Tuesday, August 6, 2002 11:12 AM

xiv Table of Contents

Multiple Network Cards 272Deleting Table Entries 273Reverse Address Resolution 273

IPV6—The Next Generation 274IPV6 Addresses 274

Traceroute 275

Conclusion 276|

12 Naming Services and NIS 277Objectives 278

Naming Services 278Local Files 278NIS 278DNS 279NIS+ 279LDAP 279Why Use Them? 279

Name Service Switch File 280Status Codes and Actions 281Template Switch Files 282

How NIS Works 283

NIS Domain Names 284

NIS Maps 284Makedbm 286Make and Makefiles 287DNS Forwarding 288

Machine Types and Daemons 288Master Server 288Slave Server 289

2-TOC.fm Page xiv Tuesday, August 6, 2002 11:12 AM

Table of Contents xv

Client 289Booting and Binding 289

Our Machines 290The Packages 291

Build the Master Server 291

Build the Clients 295

Build the Slave Servers 296

The Server Map 298

Map Propagation 299Ypxfr 299Yppush 300

Customizing NIS 300The “userAccessList” File 300Custom Map Propagation 303

NIS Passwords 304Update the User Creation Script 305Update the Makefile 306User Password Changes 306Passwd.adjunct File 308Update the User Creation Script—Again 310

Disabling NIS 310Disabling a Slave Server 311Disabling a Client 312

13 Connecting to the Internet 313Objectives 314

The Design 314

Allocating an IP Address 315

2-TOC.fm Page xv Tuesday, August 6, 2002 11:12 AM

xvi Table of Contents

Domain Names and Addresses 316Registering a Domain Name 316Our Values 316

Configuring the Interface 317

Adding a Default Route 317Host Names or Addresses 318

Enabling Host Name Resolving 318

Checking the Connection 319Nslookup 320Traceroute 320Ping 320

Configuring the Remaining Systems 321

Multiple Default Routes 322

14 Connecting Serial Devices 325Objectives 326

Serial Communication 326

Synchronous versus Asynchronous 328Start Bit 329Data Bit 329Parity 329

Speed 330Baud and BPS 330Characters per Second 330

Serial Devices 330DTE–DCE Connection 331DTE–DTE Connection 331

Serial Ports 332

2-TOC.fm Page xvi Tuesday, August 6, 2002 11:12 AM

Table of Contents xvii

Service Access Facility 333Port Monitors 333SAF Hierarchy 334SAF Log Location 336Administration Programs 336

Remove Existing Port Monitors 336

Adding a Terminal 337Add a Port Monitor 338Configure the Port Monitor 340

Ttyadm 341

Line Settings 342

Consoles and Serial Ports 343

Adding a Modem 343Test the Modem 345Configure /Etc/remote 346Test Incoming Connections 346

Conclusion 346

15 Dial ing in with PPP 347Objectives 348

Point-to-Point Protocol 348

Why Use PPP? 348

The Components 348

The System 349

Building the Connection 349

The Serial Port 350

UUCP 351Chat Scripts 352

2-TOC.fm Page xvii Tuesday, August 6, 2002 11:12 AM

xvii i Table of Contents

Devices File 353Dialers File 353Systems File 355Checking UUCP 356

PPP 357Which Configuration? 357Link Manager 357Log Files 359Testing the Link 359

Host Name Resolving 361

Name Service Caching 361

Routing 362

The Completed Network 362

Custom Scripts 363

Conclusion 364

16 Configuring DNS 365Objectives 365

What Is the Domain Name System? 366

Why Do We Need It? 366

DNS Hierarchy 367Domain Name Space 367What’s a Domain? 368Registering Domains 370

Servers and Resolving 370Name Servers 370Root Servers 372Resolvers 372

2-TOC.fm Page xviii Tuesday, August 6, 2002 11:12 AM

Table of Contents xix

Forward and Reverse Lookups 373

Zones 374Zone Transfers 375

Is It DNS, BIND, or Named? 375Named Versions 376The Boot File 376

Our Configuration 379Our Domain 379

Zone Files 380SOA Records 380NS Records 382

Master Server 383Boot File 383Root Cache 384“Localhost” Reverse File 385Master Forward File 386Master Reverse File 387

Resolv.conf File 387

Starting Named 388

Slave Server 388Boot File 388

Testing the Servers 389

Enabling Resolving 391

Configuring the Clients 392

Conclusion 393

17 Adding SCSI Devices 395Objectives 396

Introduction 396

2-TOC.fm Page xix Tuesday, August 6, 2002 11:12 AM

xx Table of Contents

What Is SCSI? 396Single-Ended versus Differential 397High versus Low Voltage Differential 399Multimode LVD 399Narrow and Wide 399Termination 399SCSI IDs 399Logical Units 400

Solaris Devices 401Physical Devices 401Logical Devices 402Instance Names 402Naming Conventions 402Autoconfiguration and /etc/path_to_inst 403

Adding the Disk 404Device Tree 405Format 407Prtvtoc 411Formatting Multiple Disks 412Add a Filesystem 413Mount the Filesystem 413

Configuring LUNs 415

Adding the Tape Drive 416Drvconfig and Devfsadm 416Checking the Tape 417Nonstandard Tape Drives 417Configuring St.conf 418

SCSI Options 420

2-TOC.fm Page xx Tuesday, August 6, 2002 11:12 AM

Table of Contents xxi

18 NFS, DFS, and Autofs 423Objectives 424

Network Filesystem 424

Distributed Filesystem 425

Autofs 425

The Build Order 425

Remote Procedure Call 426Rpcbind 426Program and Version Numbers 427Transport and Machine Independency 428External Data Representation 428RPC Database 428NFS Daemons 429Resources and Filehandles 429Client-Server Communication 431NFS Versions 431DFS Files 432

Configuring the Server 433Checking RPC 435

Setting Up the Clients 436

Server Share Options 438

Access Lists 439Using Netgroups 440

Client Mount Options 441

Authentication 442Secure NFS 444Client Failover 444NFS URL 445

2-TOC.fm Page xxi Tuesday, August 6, 2002 11:12 AM

xxii Table of Contents

The Autofs 445Master Map 446Predefined Maps 446Direct and Indirect Maps 447Map Naming Conventions 448

Our Configuration 448The Master Map 449The Direct Map 449The Indirect Maps 449

Metacharacters 450

Client Failover 451Preferred Servers and Weighting 451

Testing 451

Naming Services and Autofs 452Direct Maps 452Included Maps 453

Conclusion 453

19 Time, Date, and NTP 455Objectives 455

Introduction 456

System Time 456GMT or UTC 456Displaying Time 456Date 457Time Zones 457

Host Names 461

Rdate 461

2-TOC.fm Page xxii Tuesday, August 6, 2002 11:12 AM

Table of Contents xxiii

Network Time Protocol 462

How NTP Works 463Stratum Levels 463Delays, Offsets, and Dispersion 464Servers 466

Our Configuration 468Kernel System Variables 468Build the Clients 469Checking the Clients 471Build the Local NTP Server 472Checking NTP on the Server 473Configuring the Clients 474Checking the Clients 475The Final Configuration 476Check the Final Configuration 477

Which Is Best? 477

20 Sett ing Up the Mail System 479Objectives 479

What Is Mail? 4801. Write the Letter 4812. Address It 4823/4. Put It in an Envelope/Post It 4825. Send It to the Correct Area 4836. Local Delivery 483

Mail Protocols 485Simple Mail Transfer Protocol 485Post Office Protocol 487Internet Message Access Protocol 489Web Mail 490

2-TOC.fm Page xxiii Tuesday, August 6, 2002 11:12 AM

xxiv Table of Contents

Secure Communication 490Which Is Best? 490

DNS and Mail 491

Sendmail 492

M4 493

Sendmail and M4 494Generating the Configuration File 497Adding Functionality 498

Our Configuration 499Update DNS 500The Mail Host 500Configure the Clients 502

Aliases 504

Conclusion 505

21 Kernels and Al l About Them 507Objectives 508

What Is the Kernel? 508

How Does It All Fit Together? 508

Troubleshooting 510Truss 510Pargs 513Prex 514

Kernel Modules 514

The /etc/system File 515Kernel Parameters 515Listing Kernel Parameters 515Modifying Kernel Parameters 517

Kernel Messages 518

2-TOC.fm Page xxiv Tuesday, August 6, 2002 11:12 AM

Table of Contents xxv

22 Backing Up and Restoring the System 521Objectives 522

Why Do We Need a Backup Strategy? 522

What Is a Backup Strategy? 522

How Do We Back Up the System? 523Dd 523Tar 526Cpio 528How Do We Fit More Data on the Tape? 531Ufsdump and Ufsrestore 535

Remote Backups 539

Backup Consistency 541

The Implementation 542System File Backup 542Our Backup Strategy 543The Backup Script 544

A Sett ings Used Throughout the Book 547Overview 547

Chapter 1: User Details 547Chapter 6: Standard Disk Layout 548Chapter 11: System Details 548Chapter 14: Serial Device Details 549Chapter 15: PPP Connection Details 550Root Crontab Entry 550

2-TOC.fm Page xxv Tuesday, August 6, 2002 11:12 AM

xxvi Table of Contents

B Securi ty Checkl ist 551Objectives 551

Description 552

User Security 552

File Security 552

Network Security 553

General Security 553

Index 555

2-TOC.fm Page xxvi Tuesday, August 6, 2002 11:12 AM

37

3

USERADMINISTRATION

Manual Pages

auth_attr (4)exec_attr (4)group (4)groupadd (1M)groupdel (1M)groupmod (1M)grpck (1M)login (1)newgrp (1)passmgmt (1M)passwd (4)pfexec (1)policy.conf (4)prof_attr (4)pwck (1M)pwconv (1M)roleadd (1M)roledel (1M)rolemod (1M)shadow (4)useradd (1M)

Butler.book Page 37 Tuesday, August 6, 2002 10:54 AM

38 User Administration

O b j e c t i ve s

We briefly looked at users in Chapter 1, “The System Administrator’s Role.”Here, we’ll expand on that to examine why they are required, and look atsome of the ways in which they can be created—we’ll also point out somecommonly used shortcuts along the way!

As we work through the chapter, we’ll decide upon a set of standards foruser creation and then move on to create various users. After that, we’llexamine RBAC and create a custom script for adding users.

W h a t A r e U s e r s ?

Anyone trying to access a UNIX system requires the correct login informa-tion, which is allocated by a system administrator. At login time, you areprompted to enter your login name, followed by your password; if this is cor-

Manual Pages (Continued)

user_attr (4)userdel (1M)usermod (1M)vipw (1B)

Files Affected

User’s home directory location/etc/datemsk/etc/default/passwd/etc/exec_attr~/.cshrc~/.login~/.logout/etc/group/etc/opasswd/etc/oshadow/etc/passwd/etc/prof_attr/etc/ptmp/etc/security/auth_attr/etc/security/exec_attr/etc/security/prof_attr/etc/shadow/etc/user_attr/usr/sadm/defadduser


What Are Groups? 39

rect, you will be allowed on the system. This process is carried out for a num-ber of reasons, including the following:

• It ensures that the system remains secure by only allowing users thatknow a login name and corresponding password to access the system.

• It allows the administrator to determine who is logged on at any partic-ular time and also how much time and/or space they are using.

• It allows users to be gathered together into groups and assigned permis-sions as required.

While we often think of a user as being an actual person, this doesn’t haveto be the case. For example, users are often defined to enable a task to be eas-ily carried out, such as the shutdown user that can be used to power down themachine.

W h a t A r e G ro u p s ?

The system uses a number of mechanisms to make sure that users’ files areprotected from everyone else. Gathering related users together into “groups”is one of these mechanisms. This allows users to easily share any commonresources, and it also provides an opportunity to control file access on a groupbasis. We’ll look at user and group permissions in more detail in Chapter 4,“Permissions and All That.”

To ensure this mechanism works, each user must be a member of at leastone group, which is known as the user’s primary group. In addition, users canalso be members of a number of other groups, known as their secondarygroups.

Using secondary groups provides a degree of flexibility for the user. Forexample, assume your primary group is set to engineering and you requireaccess to files owned by the sales and marketing groups. Setting your second-ary group membership to sales and marketing would quickly solve this prob-lem. We’ll look at this in more detail in “Primary and Secondary Groups” onpage 46.

U I D s a n d G I D s

User names and group names are ideal for us to work with, but are less use-ful to the system—it prefers to deal in numbers. For this reason, when usersare created they are allocated an identity number, known as a UID (UserIdentifier). The system uses this to manage users, only displaying theirnames for our convenience. Similarly, each group is allocated a GID (GroupIdentifier), which is used in the same manner by the system.

Each user should have a unique UID. However, it’s possible to share oneand there are valid reasons for doing so, as we explained for UID 0 inChapter 1.



All the information used to identify a user is stored within a series of files:the password file, the shadow file, and the group file. Let’s look at these nowbefore we start to add any users.

Pa s s wo r d F i l e

The user’s password information is located in a file named /etc/passwd. Thisis an ASCII file and is readable by everyone, which isn’t a problem becauseall the security information is located elsewhere (as we will see later). For themoment, we’ll ignore the default entries that are in the file—suffice it to saythat they are required by the system and their use will be explained as wecome across them.

Let’s have a look at what the password file contains:

hydrogen# cat /etc/passwdroot:x:0:1:Super-User:/:/sbin/shdaemon:x:1:1::/:bin:x:2:2::/usr/bin:sys:x:3:3::/:/bin/kshadm:x:4:4:Admin:/var/adm:lp:x:71:8:Line Printer Admin:/usr/spool/lp:smtp:x:0:0:Mail Daemon User:/:uucp:x:5:5:uucp Admin:/usr/lib/uucp:nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucicolisten:x:37:4:Network Admin:/usr/net/nls:nobody:x:60001:60001:Nobody:/:noaccess:x:60002:60002:No Access User:/:nobody4:x:65534:65534:SunOS 4.x Nobody:/:hydrogen#

We can see from this example that each entry consists of the followingseven fields, each separated by a colon (:), some of which may be blank.

Field 1: Login NameA user must have a name that he or she will use to access the system. Thisname is chosen and added to the system files by the system administrator.The restrictions on this name are that:

• It must be unique.• It should contain between two and eight characters, the first being a let-

ter. It can actually be longer, but programs such as pwck (see “Checkingthe Files” on page 66) will report more than eight as an error. It is oftenan abbreviation of the user’s full name; for example, given name andsurname or first initial and surname.

• This field cannot be empty.


Password File 41

Field 2: PasswordThis originally contained the encrypted password on earlier versions of theoperating system. Nowadays, however, it may also contain information that isused in conjunction with the shadow file, which now means the followingtypes of entries are valid:

• Nothing; it may be an empty field.• An “x” to indicate to other programs that the password is located else-

where (see “Shadow File” on page 43).• An encrypted password. This is the “original” format, and may be there

for a number of reasons, such as the password has been manuallyinserted, or the file is from an old machine. The section on pwconfshows how this can be altered to the current format.

Field 3: User ID NumberThis field contains the UID, which we’ve already mentioned should be unique.However, multiple login names assigned to a common UID can be used as away of tracking specific users, as we’ll show later with the powerdown user.In summary, this field’s restrictions are as follows:

• The assigned UID should be between 0 and 60,000 for compatibility, butnote that some UID numbers are special. For example, in Chapter 1 weshowed that a UID number of 0 provides super-user privileges.

• UIDs between 0 and 99 are reserved for future use, so a good base tostart would be 100.

• This field must have a value.

Field 4: Group ID NumberThis contains the GID number of the user’s primary group; we’ll discuss thesein more detail a little later. Some default groups are predefined on the sys-tem, such as staff, operator, and other. The field restrictions are as follows:

• Any number of users can be part of a specific group.• This field should correspond to an entry in the group file.• It must have a value—we stated earlier that a user must be a member

of at least one group.• It doesn’t have to be unique.



Field 5: Comment FieldThis field is commonly termed the “gecos” field (it used to contain informa-tion used by the system that ran the “General Electric Comprehensive Oper-ating System”) and can contain a comment string of some sort. It usuallycontains the user’s full name or some similar relevant piece of information.This is because a number of other programs will read and use the contents ofthis field; for example, mail in its “From:” line and finger in its “In RealLife” line. This field can also contain an “&,” which means “use the loginname.” For example, if an entry looked like the one shown below:

demo::100:100:The users name is &:/home/demo:/bin/ksh

—then the finger command would contain “The users name is demo” in itsoutput.

This field can be empty, in which case any program that tries to use thisfield will simply output null values.

Field 6: The Home DirectoryEvery time the user logs on to the system, various start-up files are read fromthe home directory (see Chapter 5, “Shells”), after which the user is placedwithin the filesystem at this location. It is here that users are usually free tocreate files and directories and store any work. The usual method of creatinghome directories is to place all the users under a general location, such as/export/home or /home.

• The field must not be empty.• The user should have permission to access the directory specified (see

Chapter 4, “Permissions and All That”).

Field 7: The Program to Run on LoginWhen users log on to the system, the program that is specified in this field isstarted on their behalf and continues to run until they logout or exit the pro-gram. Normally the program will be a shell (see Chapter 5, “Shells”), but canbe any system program. For example, someone who is shutting down the sys-tem might run a shutdown program.

• This field can be empty, in which case the system will run the BourneShell (/bin/sh).


Shadow File 43

S h a d ow F i l e

Like the password file, the shadow file is an ASCII file with the fields sepa-rated by a colon (:). It is named /etc/shadow and is used to store security-related details, such as encrypted passwords and password aging informa-tion. For this reason, it is designed not to be readable by the general public.

The shadow file, as distributed, will look similar to that shown here:

hydrogen# cat /etc/shadowroot:<encrypted root password>:6445::::::daemon:NP:6445::::::bin:NP:6445::::::sys:NP:6445::::::adm:NP:6445::::::lp:NP:6445::::::smtp:NP:6445::::::uucp:NP:6445::::::nuucp:NP:6445::::::listen:*LK*:::::::nobody:NP:6445::::::noaccess:NP:6445::::::nobody4:NP:6445::::::hydrogen#

This example shows that for every entry in the password file, there shouldbe a corresponding entry in the shadow file. See the “Checking the Files” sec-tion on page 66 for examples of commands that can be used to keep the filesup-to-date. The field entries are as follows.

Field 1: Login NameThis field is for the user’s login name; it matches the corresponding name inthe password file. Matching on the name, rather than the UID, is required forany super-user type accounts. This is because they all share the same UID of0 and therefore need some mechanism to allow them all to login as individ-ual accounts. For example, we could create a user named powerdown by add-ing something similar to the following entry to /etc/passwd:

powerdown:x:0:1:/export/home/powerdown:/usr/sbin/halt

This user has a UID of 0, but will use a different password to the main rootaccount, thereby providing the user with the ability to shut the machinedown only.

Field 2: Encrypted PasswordIt is recommended that every user have a password to ensure that onlyauthorized users can access the system. Note that giving users passwordsdoes not deny anyone else from accessing their files; the system permissions



can be easily altered so that access can be either granted or denied to anyother user or group of users. If this field is empty, the user will not need apassword to login, although passwords can be enforced by configuring a filenamed /etc/default/login.

The encrypted password will either be a 13-character string, “NP” to indi-cate no password, or “*LK*” to indicate the account is locked—in fact, anynumber of characters less than 13 will lock the account.

Field 3: Password Change DateThis field contains the date when the password was last changed. It is shownas the number of days from January 1, 1970, or “0” if the user has been forcedto change it at the next login.

Field 4: Minimum Change DaysThis field contains the minimum number of days that must pass before theuser is allowed to change his or her password again.

Field 5: Maximum Valid DaysThis field contains the maximum number of days users can use the passwordbefore they are forced to change it.

Field 6: Number of Warning DaysThis field contains the number of days before the password expires that thesystem will start to warn the user.

Field 7: Number of Inactive DaysThis field contains the number of days of inactivity the user is allowed.

Field 8: Expiry DateThis field contains the date the account will expire. It is shown as the num-ber of days from January 1, 1970.

Field 9: Not UsedThis field is reserved for future use, so for now it should be empty.


Group File 45

G ro u p F i l e

This file is named /etc/group and is similar to the password and shadowfiles; in other words, it is an ASCII file consisting of colon-separated strings.It contains definitions for all the groups that are used on the system and, bydefault, looks like the one shown here:

hydrogen# cat /etc/grouproot::0:rootother::1:bin::2:root,bin,daemonsys::3:root,bin,sys,admadm::4:root,adm,daemonuucp::5:root,uucpmail::6:roottty::7:root,tty,admlp::8:root,lp,admnuucp::9:root,nuucpstaff::10:daemon::12:root,daemonsysadmin::14:nobody::60001:noaccess::60002:nogroup::65534:hydrogen#

The field entries are as follows.

Field 1: Group NameThis is the actual group name.

Field 2: Group PasswordThis field is largely historical and now rarely used.

• It can be empty.• It can contain an invalid encrypted password, such as an “*.”• It can contain a valid encrypted password (13 characters).

Unfortunately, there isn’t any way to get a password in here other thanmanually inserting an already encrypted password. The effects of this fieldvary depending upon whether you are a member of the group or not. Let’sleave group passwords for now and revisit them in the following section, “Pri-mary and Secondary Groups.”



Field 3: Group Identity NumberSimilar to the UID, the GID is used to store the numerical ID of a group. Thevalue should be less than 60,000 for compatibility with other systems.

Field 4: Group User ListThis contains a comma-separated list of users who are allowed to be in thisgroup. It is used in conjunction with newgrp, which we’ll look at in the follow-ing section.

P r i m a r y a n d S e c o n d a r y G ro u p s

Now, let’s try and clear up some of the confusion about how the password filerelates to the group file, and see where primary and secondary groups comeinto the picture. We’ll do this using the example users and groups listed inTable 3.1. This shows that prim_user and sec_user only have a primary groupdefinition, while the user named both_user is also a member of a secondarygroup as well.

We’ve already seen that a user’s primary group is defined by that user’sentry in /etc/passwd, and that any secondary groups the user is also a mem-ber of are defined in /etc/group. For the example users, we’ll create the fol-lowing password and group entries:

hydrogen# more /etc/passwd<lines removed for clarity>prim_user::200:500::/export/home/prim_user:/bin/kshsec_user::201:501::/export/home/sec_user:/bin/kshboth_user::202:500::/export/home/both_user:/bin/kshhydrogen#

hydrogen# more /etc/group<lines removed for clarity>prim::500:sec:MzQvs7gYIUVVQ:501:both_userhydrogen#

Table 3.1 User Details

User Name (UID) Primary Group (GID) Secondary Group (GID)

prim_user (200) prim (500) —

sec_user (201) sec (501) —

both_user (202) prim (500) sec (501)


Primary and Secondary Groups 47

We can see from the group file that the one named prim isn’t used by any-one as a secondary group. However, the group named sec is the secondarygroup for the user named both_user; it also has a password set. Now let’s suto prim_user, create a file, and check what the ownerships are on it:

hydrogen# su - prim_userhydrogen$ touch file1hydrogen$ ls -ltotal 6-rw-r--r-- 1 prim_user prim 0 Feb 26 10:44 file1hydrogen$ exithydrogen#

As expected, file1 is owned by the user prim_user, and its group ownershipis set to its primary group, prim. Now let’s do the same for sec_user:

hydrogen# su - sec_userhydrogen$ touch file1hydrogen$ ls -ltotal 6-rw-r--r-- 1 sec_user sec 0 Feb 26 10:46 file2hydrogen$ exithydrogen#

Again, the file has the correct ownerships, as expected. Now, let’s try thiswith both_user. First we’ll create a file that will take the user’s primary groupdetails. This is the user’s default group so it will be set correctly when we login as both_user.

hydrogen# su - both_userhydrogen$ touch file3hydrogen$ ls -ltotal 6-rw-r--r-- 1 both_user prim 0 Feb 26 10:46 file3hydrogen$

Good. This also works exactly as expected; the file has the correct owner-ships. However, we also know that both_user is a member of a secondarygroup. If we wish to create files owned by members of that group, we can usethe newgrp command to switch to it before creating the file—just as we wouldsu to a user if we wanted to carry out any tasks as someone else. Let’s do thatnow:

hydrogen$ newgrp sechydrogen$ touch file4hydrogen$ ls -ltotal 6-rw-r--r-- 1 both_user prim 0 Feb 26 10:46 file3-rw-r--r-- 1 both_user sec 0 Feb 26 10:47 file4hydrogen$ exithydrogen#



This shows that a different group owns each file, depending on whichgroup we had set as the primary at the time. Notice that both_user wasn’tprompted for a password when it ran newgrp. The reason for this is thatboth_user is a member of the sec group.

Now let’s see what happens when a user who isn’t a member of that grouptries to run the same command:

hydrogen# su - prim_user$ ls -ltotal 6-rw-r--r-- 1 prim_user prim 0 Feb 26 10:44 file1hydrogen$ newgrp secnewgrp: Password<enter group password>hydrogen$ touch file2hydrogen$ ls -ltotal 6-rw-r--r-- 1 prim_user prim 0 Feb 26 10:44 file1-rw-r--r-- 1 prim_user sec 0 Feb 26 10:47 file2hydrogen$ exithydrogen#

This time prim_user was prompted for the group password. Assuming wegive the correct password, our primary group will be set to the new one (sec)and any files we create will have that group ownership.

T h e I m p l e m e n t a t i o n

Now we’re ready to move on and add some users to our system. We’ve chosento add the four listed in Table 3.2.

The reasons for selecting these users are as follows:

Table 3.2 User Details

Real Name Login Name UID Group GID

Test User testuser 500 test 100

System Administrator sysadmin 1000 sysadmin 14

Mike Smith msmith 1001 staff 10

John Green jgreen 1002 staff 10



• Test User: Creating this user allows us to test a variety of things, suchas login scripts and checking initialization files, safe in the knowledgethat we won’t damage the running system. For this reason, test userswill also be maintained along with all the standard users, although theywill be placed in their own group.

• System Administrator: One of our important users. These users willbe allowed to carry out some system administration tasks. We’ll useRBAC later in the chapter to create and control them. This means thatinstead of logging in as root and having access to any command, we’lljust let them have access to the commands we want them to run. Thiswill (hopefully!) ensure that users are less likely to accidentally runsome command with disastrous affects.

• Mike Smith/John Green: Two of our genuine users—we’ll use these toshow examples of useradd and our custom script later.

Our “Company Standards”One of the first steps we need to take is to produce a set of standards thatwill be used throughout the company/department whenever we wish to addusers. For example, should the login names be their first names only (not agood idea as we would soon run out of logins), or should we have the first ini-tial followed by the next three characters of the surname? In a similar way,every other parameter is best decided upon before any users are added; other-wise, the system can become awkward to administer very quickly.

The following is a list of standards that we have decided to use for all theusers we add:

• The login names will be based on a combination of the user’s surnameand first initial. We will limit them to eight characters, leaving up toseven characters for the surname.

• UIDs will be allocated sequentially. Having a certain number of UIDsavailable for each department, say 1,000 for sales, 2,000 for engineer-ing, and so on, could be used to allocate UIDs, but this is really why thegroup file is there. Using that mechanism can also make it awkward toadminister the UIDs as users are added and deleted later.

• We will split users into groups by department or function; for example,some groups we will implement are sales, software, and marketing.Doing this will allow us to restrict access to documents within each spe-cific batch of users as required.

• All users will use the Korn Shell (see Chapter 5, “Shells”). We will set upsome global start-up files to easily maintain them by linking users tothis global file where possible.

• All users’ home directories will be located in /export/home.



• All users will be created with a default password of “changeme” and willbe forced to change it at first login.

• Password aging will be used to force users to change their password atpredefined intervals, this being 60 days.

• The system will warn users five days before the password expires that itrequires changing.

Now let’s start to create the users. There are various ways that this can bedone—some easier than others. The first, and recommended way is by using acommand named useradd or one of its variants (groupadd, roleadd, and soforth). These are the command line equivalents of the GUI admintool andare the methods we’ll look at for the majority of users. They will perform allthe tasks necessary to create the user, including things like making sure thatduplicate UIDs aren’t used.

A second method is to update all the relevant system files manually. Thisis a common task carried out by many system administrators, but the respon-sibility of getting things correct also rests with them—the system cannotcheck that everything has been carried out correctly.

A third method is to create a custom script that will enable us to “auto-mate” the tasks that we need to perform to add the users and apply company-specific settings at the same time. Again, this is a common way to add users,often written as shell scripts, Perl scripts, or C programs. We’ll actually cre-ate a simple example, based on useradd, at the end of this chapter.

Adding a Test User with Groupadd and UseraddTo demonstrate the use of useradd, we’ll create the test user and associatedgroup first. First let’s create the group as follows:

hydrogen# groupadd -g 100 testhydrogen#

Now check that the group has been successfully added to the /etc/groupfile:

hydrogen# grep test /etc/grouptest::100:hydrogen#

Good. We’ve defined the new group, so we can go ahead and create the testuser:

hydrogen# useradd -c "Test User" -d /export/home/testuser -g test -m -k /etc/skel -u 500 -s /bin/ksh testuser6 blockshydrogen#



If we look at the entry that has been created in /etc/passwd, we can seethere is an “x” in the password field. This indicates there is a correspondingshadow entry, as we mentioned earlier:

hydrogen# grep testuser /etc/passwdtestuser:x:500:100:Test User:/export/home/testuser:/bin/kshhydrogen#

Looking at the /etc/shadow entry, we can see the password is set to thelocked string “*LK*” to show the account is locked. The account is automati-cally locked after it has been created with useradd:

hydrogen# grep testuser /etc/shadowtestuser:*LK*:::::::hydrogen#

We could also have checked the password state by running the passwdcommand. This will display the status of the account and any aging details ifthey’ve been set. In this case it again confirms the password is locked:

hydrogen# passwd -s testusertestuser LKhydrogen#

Setting the PasswordWe need to unlock the account before the user can login, so we will do that byallocating a password to the user using the passwd command.

hydrogen# passwd testuserNew password: <enter user's password>Re-enter new password: <enter user's password>passwd (SYSTEM): passwd successfully changed for testuserhydrogen#

If we again check the shadow file, we can see that the user now has a validpassword entry and can log in to the account correctly. Notice the password isencrypted and field 3 displays when this was altered. This is shown as thenumber of days since January 1, 1970.

hydrogen# grep testuser /etc/shadowtestuser:ba7btwLghQU86:10912::::::hydrogen#

As seen here, passwd will show us that the account has a valid passwordassigned:

hydrogen# passwd -s testusertestuser PShydrogen#



Now, let’s reset it to our standards for the company, which are five dayswarning and 60 days valid:

hydrogen# passwd -f -w 5 -x 60 testuserhydrogen#

Looking at the shadow file, we can see the settings have been applied.Fields 3 and 4 are both set to “0” to force users to change their passwords atthe next login.

hydrogen# grep testuser /etc/shadowtestuser:ba7btwLghQU86:0:0:60:5:::hydrogen#

Once more, if we check this via passwd, it will also show the followingaging details:

hydrogen# passwd -s testusertestuser PS 00/00/00 0 60 5hydrogen#

Testing the AccountAt this point, we can confirm that the user has been set up correctly byswitching to that person’s account. To do this, we’ll run the following com-mand and should see that the system offer us the user’s default prompt:

hydrogen# su - testuserhydrogen$

The “-” option will force su to reset the new environment to that of tes-tuser. Once we have logged in and proven the account is OK, we can exit backto the root shell:

hydrogen$ exithydrogen#

Modifying with UsermodUsermod allows us to modify the user’s definition. As an example, we’ll mod-ify testuser so that it is included in additional groups such as sys and adm.First, let’s confirm that testuser is only in the one group at present. We can dothis by using grep to search the /etc/group file as we have shown previously,or by running a command named groups, as shown below:

hydrogen# groups testusertesthydrogen#



Now that we know that testuser is only in the test group, let’s modify itssettings:

hydrogen# usermod -G sys,adm testuser6 blockshydrogen#

Checking the group file shows the details have been added correctly:

hydrogen# grep testuser /etc/groupsys::3:root,bin,sys,adm,testuseradm::4:root,bin,sys,adm,testuserhydrogen#

Similarly, if we run groups, it provides us with a similar confirmation:

hydrogen# groups testusertest adm syshydrogen#

Removing the UserThe account has now been created and we have finished with it for themoment, so we want to ensure the system is secure by making sure no one isallowed access to it. We could achieve this by either deleting or locking theaccount. Deleting it would remove it from the system and mean that we can-not use it again for testing and so forth, while locking the account allows usto simply lock or unlock it at will. If we wished to delete it, we could run theuserdel command as shown below:

hydrogen# userdel -r testuserhydrogen#

Rather than remove the account, let’s retain it for the moment, as this willallow us to use it to test similar user tasks. Therefore, we’ll lock the accountto ensure that it is secure:

hydrogen# passwd -l testuserhydrogen#

Now we can check that the account has been locked; passwd will providethis information for us and also show the date the password was altered:

hydrogen# passwd -s testusertestuser LK 12/25/99 0 60 5hydrogen#



Useradd DefaultsWhen adding users with useradd, it’s possible to configure some settings thatcan be used as defaults. Let’s take a look at these to see what they are cur-rently set to:

hydrogen# useradd -Dgroup=other,1 basedir=/home skel=/etc/skel shell=/bin/sh inactive=0 expire=hydrogen#

This shows that we need to alter a couple of the values to fall in line withour standards—these being the basedir, group, and shell values. The firstproblem we can see is that useradd will not allow us to change the defaultshell. We’ll look at this problem in a minute. First, let’s set the default groupto be staff, and the basedir directory to be /export/home:

hydrogen# useradd -D -g 10 -b /export/homegroup=staff,10 basedir=/export/home skel=/etc/skel shell=/bin/sh inactive=0 expire=hydrogen#

Good. The details have been altered correctly. Once the default values arechanged, they are written away to a file named /usr/sadm/defadduser. Thisdoesn’t exist by default; it’s created the first time this command is run. If welook at the file we’ll find it now contains the following details:

hydrogen# cat /usr/sadm/defadduser# Default values for useradd. Changed Wed Nov 17 12:13:00 1999defgroup=10defgname=staffdefparent=/export/homedefskel=/etc/skeldefshell=/bin/shdefinact=0defexpire=hydrogen#

This shows the new settings, along with the current default shell value.Defadduser is simply a text file, read by useradd, so let’s manually alter thedefshell variable and set it’s value to /bin/ksh:

hydrogen#<edit /usr/sadm/defadduser and alter defshell=/bin/sh to defshell=/bin/ksh>hydrogen# grep defshell /usr/sadm/defadduserdefshell=/bin/shhydrogen#

If we again run useradd to display the current default settings, we can seethat the shell has been altered correctly:



hydrogen# useradd -Dgroup=staff,10 basedir=/export/home skel=/etc/skel shell=/bin/ksh inactive=0 expire=hydrogen#

Now that we’ve got the correct default values set, we can easily createusers by specifying the minimum amount of information, such as that shownbelow:

hydrogen# useradd -c "Test User" -m -u 500 testuser6 blockshydrogen#

Manually Updating the System FilesWe mentioned at the beginning of this chapter that we would also show someshortcuts for adding users. We’ll do that here, but before we do, we need to beaware that using these methods can be unsafe. The reason for this is thatusing them removes the safety checks built into programs such as useradd.For example, these programs maintain a backup copy of the major files andalso perform some error checking, such as making sure the user doesn’talready exist and that a unique UID is used.

However, for performing quick changes and things such as root passwordrecovery, the manual method is ideal, and sometimes a necessity.

Let’s run through the steps here by creating one of our “standard” users,msmith, a member of the staff group. We’ll begin by checking the group file toensure the staff group is there (it should be as it’s a default group):

hydrogen# grep staff /etc/groupstaff::10:hydrogen#

Next, we’ll create an entry for the user in /etc/passwd by editing it withour favorite editor. After the changes have been made it will look like thefollowing:

hydrogen# grep msmith /etc/passwdmsmith:x:1001:10:Mike Smith:/export/home/msmith:/bin/kshhydrogen#

Now, we’ll create the corresponding entry in /etc/shadow. This should con-tain the entry shown below after it has been altered:

hydrogen# grep msmith /etc/shadowmsmith:*LK*:0:0:60:5:::hydrogen#

Here we have added the correct line, locked the account, and set the val-ues for the expiration and warning days. Now let’s create the user’s homedirectory:



hydrogen# mkdir –p /export/home/msmithhydrogen#

Solaris supplies a series of set-up files that are available for users. Theseare located in /etc/skel and named local.profile, local.cshrc, and local.login—these being for the Korn, Bourne, and C Shells. Useradd will copy the correctfile into the user’s home directory when it is created (renaming it in the pro-cess), but we need to do that manually here. We’ll do that now for the particu-lar shell that is being used, which in this case is the local.profile for the KornShell (see Chapter 5, “Shells”):

hydrogen# cp /etc/skel/local.profile /export/home/msmith/.profilehydrogen#

Now that we have all the basic files in place, we need to ensure thatmsmith can work with them and that he has permission to create files withinhis home directory. Let’s change the ownership of it now, along with any filesbeneath it:

hydrogen# chown -R msmith:staff /export/home/msmithhydrogen#

If we now list the newly created directory, we should see something simi-lar to that shown below:

hydrogen# ls -ld /export/home/msmithdrwxr-xr-x 2 msmith staff 512 Oct 22 1999 /export/home/msmithhydrogen#

Now that the user has a valid home directory, we can set the password,which we’ll do as follows. This will allow him to log in, but because we’ve alsoforced him to change his password at login time (fields 3 and 4 are set to “0”),he will be prompted to enter a new one:

hydrogen# passwd msmithNew password: <enter user's password>Re-enter new password: <enter user's password>passwd (SYSTEM): passwd successfully changed for msmithhydrogen#

Good. Everything is in place; so let’s test the account by trying to login asthe user:

hydrogen# su - msmithhydrogen$ pwdhydrogen$ /export/home/msmithhydrogen$ exithydrogen#

Good. Msmith has now been added to the system. This example shows thatmanually adding users is not a difficult task to perform—we just need to becareful and apply a few checks along the way.


Using RBAC 57

Real and Effective IDsWe’ve come across the su command in a number of places now. In Chapter 1,it was to switch from a “normal” user to root, and in this chapter to switchfrom root to a “normal” user. Before we move on, let’s take a brief look atsome of the changes that occur when we run this command.

We already know that all users have a UID and GID associated withthem—we’ve set these in the password file and can confirm what these are byrunning the id command, as shown below:

hydrogen# iduid=0(root) gid=1(other)hydrogen#

When you switch to another user, you need to inherit the UID and GID ofthe new user; otherwise, you won’t be able to access the same files as thatuser. However, the system still needs to retain your original UID and GID sothat it can reset correctly when you exit back to yourself. It accomplishes thisby assigning you an “effective” UID and GID, known as your EUID andEGID, respectively.

To show this, let’s run the id command again, but this time we’ll switch totestuser first:

hydrogen# su – testuserhydrogen$ iduid=500(testuser) gid=100(test)hydrogen$

Just as we expected—the system now believes that we are testuser. How-ever, we can still determine our original values using a number of com-mands, including who, as shown below:

hydrogen$ iduid=500(testuser) gid=100(test)hydrogen$ who am iroot console Feb 16 13:34hydrogen$

U s i n g R BAC

Up to this point, we’ve managed to create some “normal” users, in addition toour existing super-user (root). The problem we now find is that the normalusers have little power, while root has absolute power—we don’t have any-thing in between! Unfortunately, this is the way UNIX has worked for quitesome time.

Now, however, we can use a package known as RBAC (Role Based AccessControl), which we briefly described in Chapter 1, to provide the functional-ity we want. Using RBAC allows us to accurately control which tasks userscan perform and, therefore, reduce the risk of anyone accidentally destroyingthe system.



Therefore, in this section, we’ll try to balance the power a little by creatinga user that possesses some of root’s capabilities. The user we’ve chosen forthis is the system administrator, which was listed earlier in Table 3.2.

How It WorksThe steps we’ll follow to configure RBAC are very similar to the ones we’vealready carried out for adding users, but in this case we’re simply adding arole that a user will later assume. The commands used to do this are namedroleadd, rolemod, and roledel and are almost identical to those used toadminister the normal users—useradd, usermod, and userdel; in fact, thenewer role* commands are linked to the older user* ones.

RBAC uses a set of components known as authorizations, profiles, androles for its implementation. Each of these has an associated database, whichis actually a flat ASCII text file.

AuthorizationsFirst, let’s look at authorizations. These are allocated to users (or roles) togive them the right to carry out a specific task, such as changing user pass-words. Each authorization has a name associated with it, which is used as itsreference and is written in a dotted notation that represents a hierarchy ofprivileges.

For example, if you have an authorization of solaris.admin.usermgr.*, youwill be allowed to carry out most tasks associated with administering users,whereas if you have solaris.admin.usermgr.read, you will only be allowed toview user details.

The authorizations that can be assigned are defined in a file named /etc/security/auth_attr. If we look at this we’ll see that it contains the followingtype of information:

hydrogen# more /etc/security/auth_attr<lines removed for clarity>solaris.admin.usermgr.:::User Accounts::solaris.admin.usermgr.write:::Manage Users:: help=AuthUsermgrWrite.htmlsolaris.admin.usermgr.read:::View Users and Roles::help=AuthUsermgrRead.htmlsolaris.admin.usermgr.pswd:::Change Password:: help=AuthUserMgrPswd.htmlsolaris.admin.logsvc.:::Log Viewer::<lines removed for clarity>

Here we can see that like many administrative files, auth_attr is split intofields using colon-separated strings. The field we are really interested in hereis the first one, which is the name of the authorization itself and is the infor-mation we’ll use later.

ch03.fm Page 58 Tuesday, August 6, 2002 5:27 PM

Using RBAC 59

Table 3.3 provides a guide to the database fields, using one of the entriesfrom the file extract above as an example. Be aware that presently theseauthorizations are fixed and cannot be extended or altered in any way.

ProfilesOnce we have a list of authorizations, we can create a profile. Essentially, pro-files allow us to group together a number of authorizations by assigning thema name. This information is split over two locations: the profile database andthe exec database.

Profile DatabaseThe available profiles are located in /etc/security/prof_attr. Again, this is acolon-separated file, an example of which is shown below:

hydrogen# more /etc/security/prof_attr<lines removed for clarity>Primary Administrator:::Can perform all administrative

tasks:auths=solaris.*,solaris.grant;help=RtPriAdmin.htmlSystem Administrator:::Can perform most non-security adminis-

trative tasks:profiles=Audit Review,Printer Management,Cron Management,Device Management,File System Management,Mail Management,Maintenance and Repair,Media Backup,Media Restore,Name Service Management,Network Management,Object Access Management,Process Management,Software Installa-tion,User Management,All;help=RtSysAdmin.html

Operator:::Can perform simple administrative tasks:pro-files=Printer Management,Media Backup,All;help=RtOpera-tor.html

<lines removed for clarity>

Let’s take a look at one of the entries to see what information the fieldscontain. Table 3.4 uses the “Operator” entry above to show this information.

Table 3.3 Authorization Database Details

Field Description

solaris.admin.usermgr.write The authorization name

(empty) Reserved for future use


Manage Users Short descriptive text

(empty) Long descriptive text

help= AuthUsermgrWrite.html The attributes for this authorization



This shows that single authorizations, a hierarchy of authorizations, oranother profile can be included in the security attributes of a profile. Forexample, let’s assume we have the following profile:

Dummy Profile:::This is a dummy profile:\auths=solaris.admin.usermgr.read,\ solaris.admin.usermgr.write

This only allows the user to read and manage user accounts, but not tochange any passwords, as this requires the solaris.admin.usermgr.pwsdauthorization. However, if we wanted to let this role carry out any usermgrtasks, we could simply assign the higher-level authorization, as shown below:

Dummy Profile:::This is a dummy profile:\auths=solaris.admin.usermgr.*

Exec DatabaseThis file, named /etc/security/exec_attr, is used to control the securityattributes for commands used within a profile. It defines an “object identi-fier,” which is the path name of the command to be run. This may include the“*” metacharacter, to specify more than one file, such as /usr/sbin/*. Eachentry also includes the account details that may be set when the command isrun, such as the UID, GID, EUID, and EGID.

Let’s have a look at an example of this file now:

hydrogen# cat /etc/security/exec_attrPrimary Administrator:suser:cmd:::*:uid=0;gid=0Name Service Security:suser:cmd:::/usr/sadm/bin/ smattrpop:uid=0;gid=sysSoftware Installation:suser:cmd:::/usr/bin/pkgparam:uid=0Network Management:suser:cmd:::/usr/sbin/in.named:uid=0File System Management:suser:cmd:::/usr/sbin/mount:uid=0Software Installation:suser:cmd:::/usr/bin/pkgtrans:uid=0

Table 3.4 Profile Database Details

Field Description

Operator The profile name



Can perform simple administrative tasks Long descriptive text

profiles=Printer Management,Media Backup,All;help=RtOperator.html

The security attributes of the profile


Using RBAC 61

If we take one of the entries as an example, we can see that each entry isonce more split into colon-separated fields. Table 3.5 uses the “SoftwareInstallation” entry above to show this information.

RolesNow that we’ve created a profile (which contains some authorizations), wecan generate a role, assign it the new profile, and, lastly, assign the role to auser. Once we have done this, the user can assume the role at any time bysimply switching to it using su, as we’ve done before between users.

The role information is stored in a file named /etc/user_attr. Let’s look atthe default file for a moment to see what it contains—ours is shown here:

hydrogen# cat /etc/user_attrroot::::type=normal;auths=solaris.*,solaris.grant;profiles=All

Again, we can see that this file is formatted in a similar fashion to the pre-vious ones. The “root” entry fields are described in Table 3.6.

Table 3.5 Exec Database Details

Field Description

Software Installation The profile name

suser The policy associated with the profile—“suser” is the only valid policy

cmd The object type—“cmd” is the only valid object



/usr/bin/pkgparam The object identifier

uid=0 The security attribute list

Table 3.6 User Database Details

Field Description

root The user name




type=normal;auths=solaris.*,solaris.grant;profiles=All

The security attributes of the role



In this example, we can see that root has been assigned all the availableprofiles and authorizations, as expected.

Create the System Administrator RoleNow that we’ve seen the format of the files, let’s go ahead and create thesysadmin role. This is the one that users will be forced to switch to in order tobe able to perform any system administration tasks:

hydrogen# roleadd -c "System Administrator" -d /export/home/sysadmin -g sysadmin -m -k /etc/skel -u 1000 -s /bin/ksh –P "System Administrator" sysadmin

6 blockshydrogen#

Next we’ll assign a password to the role—just as we would if it were a nor-mal user:

hydrogen# passwd sysadminNew password: Re-enter new password: passwd (SYSTEM): passwd successfully changed for sysadminhydrogen#

Good. The role has been added, so now let’s have a look at the databasefiles to see what changes have been carried out:

hydrogen# grep sysadmin /etc/passwdsysadmin:x:1000:14::/export/home/sysadmin:/bin/kshhydrogen#

hydrogen# grep sysadmin /etc/shadowsysadmin:tJfxIIKL03KSA:11787::::::hydrogen#

hydrogen# cat /etc/user_attr<lines removed for clarity>root::::type=normal;auths=solaris.*,solaris.grant;profiles=Allsysadmin::::type=role;profiles=System Administratorhydrogen#

This shows that the /etc/passwd and /etc/shadow entries appear to be asnormal; the one that is different is the entry in /etc/user_attr. In here we’vedefined a role named sysadmin that is based on the System Administratorprofile. If we do a quick check on this profile in /etc/security/prof_attr, we’llsee that it provides sysadmin with the following authorizations:

hydrogen# more /etc/security/prof_attr<lines removed for clarity>System Administrator:::\ Can perform most non-security administrative tasks:\ profiles=Audit Review,\


Using RBAC 63

Printer Management,\ Cron Management,\ Device Management,\ File System Management,\ Mail Management,\ Maintenance and Repair,\ Media Backup,\ Media Restore,\ Name Service Management,\ Network Management,\ Object Access Management,\ Process Management,\ Software Installation,\ User Management,\ All;\ help=RtSysAdmin.html<lines removed for clarity>hydrogen#

We haven’t actually assigned the profile to anyone yet, so we shouldn’t beable to use it—let’s confirm this using our testuser login. First, we’ll need tosu to testuser:

hydrogen# su - testuserhydrogen$ su - sysadminPassword:Roles can only be assumed by authorized userssu: Sorryhydrogen$

OK, so now we’ll allocate the profile to testuser, which we can do usingusermod. After that we’ll try to switch to the role again:

hydrogen# usermod -R sysadmin testuserhydrogen# su - testuserhydrogen$ su - sysadminPassword:hydrogen$

Good. This time testuser was able to access the account. If we take a look in/etc/user_attr, we’ll see the reason why we’re allowed to do so:

hydrogen# cat /etc/user_attr<lines removed for clarity>root::::type=normal;auths=solaris.*,solaris.grant;profiles=Allsysadmin::::type=role;profiles=System Administratortestuser::::type=normal;roles=sysadminhydrogen#

An entry for testuser has been added to user_attr, stating that testuser canassume the sysadmin role. This means we now have a sysadmin user that isallowed to run some super-user related commands.

An interesting point to note is that if we compare the entries for root andsysadmin in /etc/auth_attr, we can see that the “type” fields are different.



This defines whether the account is a role (type=role) or whether a user canlogin directly to the account (type=normal). In other words, we can login asroot or testuser, but not as sysadmin. Instead someone must assume its role—and that can only be done by testuser.

C r e a t i n g a C u s t o m S c r i p t

Now that we’ve looked at some of the different tools that are available foradministering the user base, let’s create a script that will take us a step fur-ther by automating some of the creation steps. This is a common require-ment for many companies, because not only does it ease the task of usercreation, it also allows us to enforce a set of standards, such as setting adefault password, forcing a specific environment or login name, and so forth.The one shown here, for example, performs the following functions:

• Sets the user’s initial password to the company default• Sets the password time-out values• Forces users to change their passwords at first login• Implements quotas for the user

It’s worthwhile making a few points before we look at the script. Firstly,we’ve tried to use the supplied tools whenever possible, rather than rely onmanually editing the files. This provides us with the “safety buffer” we talkedabout earlier (backup copies of files, UID checking, etc.). That said, the onlyway we can enter a password using a shell script is to manually edit the files,which we’ve done using sed to insert an already encrypted password. If youneed to perform something different, such as generate a different passwordfor each user, then you’ll need to use programs such as C or Perl to do this.

Lastly, near the end of the script, there is room for adding any company-specific settings that you need to apply, such as updating user profiles and soforth. We’ve used this section to initialize the user’s quotas by copying themfrom an existing user:

hydrogen# cat createUser#!/bin/ksh## A script to create users in a "company format."# This uses a default, encrypted passwd that has been# obtained by pulling a known password from the shadow# file. The users are forced to alter it as first login.# It assumes the group already exists and is valid.#

## set our company defaults#home=/export/homeshell=/bin/kshskel=/etc/skel


Creating a Custom Script 65

password=hViVZtexneY8Y # default encrypted password (changeme)warnDays=5validDays=60tmpPasswd=/tmp/passwd.$$quotaAccount=testuser## check we have the correct number of params#if [ $# -ne 3 ]; then echo "Usage: ${0} <login name> <gid> <comment>" exit 1fi## grab the user info#user=$1gid=$2comment=$3## check the group is valid#egrep -s "${gid}" /etc/groupif [ $? -ne 0 ]; then echo "Please enter a valid gid and re-run" exit 1fi## add the user to the passwd file#useradd -c "${comment}" -d ${home}/${user} -g ${gid} -m -k ${skel} -s ${shell} ${user}## insert the password to the password file# (see below why the passwd and not the shadow file)#sed -e "s/^${user}:x:/${user}:${password}:/" /etc/passwd > ${tmpPasswd}if [ -s ${tmpPasswd} ]; then mv ${tmpPasswd} /etc/passwd if [ $? -ne 0 ]; then echo "Error: Cannot copy new password file" exit 1 fifi## we are setting warning and expiration dates, so# shadow needs to know when the password was updated –# let pwconv handle this for us#pwconv## set the password timeouts#passwd -f -w ${warnDays} -x ${validDays} ${user}## update the account with any "standard" settings#



edquota -p ${quotaAccount} ${user}exit 0hydrogen#

So now that we’ve got the script, how do we run it? This is actually verysimple: The script checks for three arguments being passed in—the loginname, the GID, and a comment for the “gecos” field. To run it for one of ourexample users, say John Green, we would enter the following command:

hydrogen# createUser jgreen 10 "John Green"6 blockshydrogen#

C h e ck i n g t h e F i l e s

As users are added, updated, and deleted it’s quite easy for the administra-tive files to get out of sync with each other—especially if any manual file editshave been performed. Therefore, in this last section we’ll look at a few of theutilities that can be used to check and maintain the related files (/etc/passwd, /etc/shadow, and /etc/group).

Pwconv

We’ve already come across pwconv—it was used in our custom script earlier.It is used to create or update the shadow file, which it does by synchronizingit with the password file.

It uses the second field of /etc/passwd (the encrypted password field) toindicate that the password for this user can be found in /etc/shadow. It doesthis by moving the encrypted password into /etc/shadow and replacing theoriginal password field in /etc/passwd with an “x.”

This means that if the field is empty, pwconv will create an entry in theshadow file and insert the required “x” into the password file. Similarly, ifthere is an entry in the shadow file and nothing in the password file, it willremove the shadow entry. It is intelligent enough to know that if a passwordexists in /etc/passwd, but there isn’t an entry for the user in the /etc/shadow file, it may be an old-style password file that is being used. In thiscase, it will create the correct entry in the shadow file and also move thepassword there too.

Let’s look at the following example, which uses the old-style passwordentry. In other words, the encrypted password is stored in /etc/passwd andthe user doesn’t have a /etc/shadow entry:

hydrogen# grep testuser /etc/passwdtestuser:ba7btwLghQU86:500:100:Test User:/home/testuser:/bin/kshhydrogen#


Checking the Files 67

Running pwconv and looking at the two files again will give the followingresult:

hydrogen# grep testuser /etc/passwdtestuser:x:500:100:Test User:/home/testuser:/bin/kshhydrogen#

hydrogen# grep testuser /etc/shadowtestuser:ba7btwLghQU86:::::::hydrogen#

Pwck and GrpckTwo programs, named pwck and grpck are supplied to check the contents of/etc/passwd and /etc/group, respectively. They will look for missing pass-words, incorrect fields, and so on.

To illustrate this, let’s alter the testuser’s shell to be something that is non-existent, say /bin/nosuchshell. The output from pwck will report an erroras shown below:

hydrogen# passmgmt -m -s /bin/nosuchshell testuserhydrogen# pwcktestuser:x:500:100::/export/home/testuser:/bin/nosuchshell Optional shell file not foundhydrogen#

Using grpck to check the group file may display something similar to thatshown below:

hydrogen# grpckbin::2:root,bin,daemon bin - Duplicate logname entry (gid first occurs in passwd entry)

sys::3:root,bin,sys,adm sys - Duplicate logname entry (gid first occurs in passwd entry)hydrogen#

Passwd

We saw earlier that the passwd command can be used to display a user’sdetails. As a further note, by running it as shown here we can display all theentries in the /etc/passwd file. From there, we can carry out tasks such assearching to locate all locked accounts (LKs) or all accounts without a validpassword (NP).

hydrogen# passwd -saroot PS daemon LK bin LK



sys LK adm LK lp LK smtp LK uucp LK nuucp LK listen LK nobody LK noaccess LK nobody4 LK testuser LK 12/07/99 0 60 5hydrogen#

C o n cl u s i o n

In this chapter, we’ve worked through the various methods that can be usedto add users to the system and created our users in the process. We’ve alsomanaged to create a system administrator account, using RBAC, which canperform some of the general system administration tasks.

Lastly, we’ve produced a script and looked at some associated programsthat can be used to ease and maintain general user administration tasks.


solaris operating environment boot campptgmedia.pearsoncmg.com/imprint_downloads/informit/... ·...

Documents