Home arrow Site Administration arrow Page 2 - Managing Users Part 1

Critical Skill 1 - Understand User Properites - Administration

This first part of chapter 5 "Module 5: Managing Users" covers understanding user properties and user databases. It also examines the technique of managing users for a single host. It starts by exploring the actual database files that contain information about users and moves on to the system tools available to manage the files automatically. (from the book Linux Administration, A Beginner's Guide, third edition by Steven Graham and Steve Shah, McGraw-Hill/Osborne, ISBN:0072225629, 2002).

  1. Managing Users Part 1
  2. Critical Skill 1 - Understand User Properites
  3. Shells, Startup Scripts and Mail
  4. Critical Skill 2 - Understand the User Databases
  5. The /etc/shadow File and The /etc/group File
By: McGraw-Hill/Osborne
Rating: starstarstarstarstar / 7
June 23, 2004

print this article



In Linux, everything has an owner attached to it. Given this, it is impossible for a Linux system to exist without users! At the very least, it needs one root user; however, most Linux distributions ship with several special users set up. These users work well as self-documentation tools since each user owns all of the files related to his or her username--for example, the user www is set up to own all files related to World Wide Web service. These users are configured in such a way that grants access only to a select few, so you do not have to worry about their abuse.

TIP: When possible, run applications without root privileges. (The Apache server, for example, knows how to give up root privileges before it starts accepting connections.) The benefit of doing this is that if an application is found to have a security problem, it cannot be exploited to gain system privileges.

A few things need to be set up for a user’s account to work correctly. In this section, we discuss those items and why they need to be there. The actual process of setting up accounts is discussed in “Utilize User Management Tools” later in the module.

Home Directories

Every user who actually logs in to the system needs a place for configuration files that are unique to the user. This place, called a home directory, allows each user to work in a customized environment without having to change the environment customized by another user—even if both users are logged in to the system at the same time. In this directory, users are allowed to keep not only their configuration files but their regular work files as well.

For the sake of consistency, most sites place home directories at /home and name each user’s directory by their login name. Thus, if your login name were sshah, your home directory would be /home/sshah. The exception to this is for system accounts, such as a root user’s account. Here, home directories are usually set to be either / or something specific to the need for that account (for example, the www account may want its home directory set to /usr/local/apache if the Apache Web server is installed). The home directory for root is traditionally / with most variants of UNIX. Many Linux installations use /root.

The decision to place home directories under /home is strictly arbitrary, but it does make organizational sense. The system really doesn’t care where we place home directories so long as the location for each user is specified in the password file (discussed in “The /etc/passwd File” later in this module). You may see some sites use /u or break up the /home directory by department, thereby creating /home/engineering, /home/accounting, /home/admin, and so on, and then have users located under each department. (For example, Dr. Bosze from engineering would be /home/engineering/bosze.)


Every account should either have a password or be tagged as impossible to log in to. This is crucial to your system’s security—weak passwords are often the cause of a compromised system security.

The original philosophy behind passwords is actually quite interesting, especially since we still rely on a significant part of it today. The idea is simple: instead of relying on protected files to keep passwords a secret, the system would encrypt the password using an AT&T-developed (and National Security Agency–approved) algorithm called Data Encryption Standard (DES) and leave the encrypted value publicly viewable. What originally made this secure was that the encryption algorithm was computationally difficult to break. The best most folks could do is a brute force dictionary attack where automated systems would iterate through a large dictionary and rely on the nature of users to pick English words for their passwords. Many people tried to break DES itself, but since it was an open algorithm that anyone could study, it was made much more bulletproof before it was actually deployed.

When users entered their passwords at a login prompt, the password they entered would be encrypted. The encrypted value would then be compared against the user’s password entry. If the two encrypted values matched, the user was allowed to enter the system. The actual algorithm for performing the encryption was computationally cheap enough that a single encryption wouldn’t take too long. However, the tens of thousands of encryptions that would be needed for a dictionary attack would take prohibitively long. Along with the encrypted passwords, the password file could then also keep information about the user’s home directory, UID, shell, real name, and so on without having to worry about system security being compromised if any application run by any user would be allowed to read it.

But then a problem occurred: Moore’s Law on processor speed doubling every 18 months held true, and home computers were becoming fast enough that programs were able to perform a brute force dictionary attack within days rather than weeks or months. Dictionaries got bigger and the software got smarter. The nature of passwords needed to be reevaluated.

Shadow passwords were one solution. In the shadow password scheme, the encrypted password entries were removed from the password file and placed in a separate file called shadow. The regular password file would continue to be readable by all users on the system, and the actual encrypted password entries would be readable only by the root user. (The login prompt is run with root permissions.) Why not just make the regular password file readable by root only? Well, it isn’t that simple. By having the password file open for so many years, the rest of the system software that grew up around it relied on the fact that the password file was always readable by all users. Changing this would simply cause software to fail.

Another solution has been to improve the algorithm used to perform the encryption of passwords. Some distributions of Linux have followed the path of the FreeBSD operating system and used the MD5 scheme. This has increased the complexity of being able to crack passwords, which, when used in conjunction with shadow passwords, works quite well. (Of course, this is assuming you make your users choose good passwords!)

TIP:  Choosing good passwords is always a chore. Your users will inevitably ask, “What then, O Almighty System Administrator, makes a good password?” Here’s your answer: a non-language word (not English, not Spanish, not German, not human-language word), preferably with mixed case, numbers, and punctuation—in other words, a string that looks like line noise. Well, this is all nice and wonderful, but if a password is too hard to remember, most people will quickly defeat its purpose by writing it down and keeping it in an easily viewed place. So better make it memorable! I prefer the technique of choosing a phrase and then picking the first letter of every word in the phrase. Thus, the phrase “coffee is VERY GOOD for you and me” becomes ciVG4yam. The phrase is memorable even if the resulting password isn’t.

This chapter is from Linux Administration, A Beginner's Guide, third edition, by Graham and Shah. (McGraw-Hill/Osborne, 2002, ISBN: 0072225629). Check it out at your favorite bookstore today. Buy this book now.

>>> More Site Administration Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: