The fourth field is the primary GID (group identification) number. Every user belongs to a group. Some distributions use a common group such as “users” to which everyone belongs. Others create “private groups” and assign each user to his own private group as their primary or default group. Caldera uses a common group, while Red Hat and Debian use private groups. I would recommend reading the Red Hat Users Manual, available via anonymous FTP from ftp.redhat.com/pub/redhat/redhat-4.1/Users-Guide/ in various formats. A discussion of private groups as they relate to easing the system administration burden can be found in this manual.
To discover the groups they belong to, users can type groups at the command prompt. The first group name returned is the default group. Files saved by that user will, by default, have the group identifier set to the first value returned unless the subdirectory has the “setgid” bit turned on.
The fifth field is a comment, which usually contains the user's full name. You may see this field referred to as a gecos (General Electric Comprehensive Operating System) field. Shadow files sometimes use this field for something other than a user's name, but only under special circumstances.
The sixth field is the user's home directory. The cd command given with no argument or with the tilde (~) as an argument will move the user to this directory. This directory must have a full path name, i.e., start at the root and go down. One notable exception to this rule is the system user “bin”, which has a relative path of bin as the home directory, because several bin directories exist on the system.
The last field is the user's default shell. Most Linux distributions (in fact, all of those I am aware of) default to bash, the Bourne Again Shell. For most users, this is probably the best overall shell. C programmers tend to like the syntax of one of the C shells (csh or tcsh), but for writing scripts, most users will do better with bash. If you need a user to have a system entry for any purpose (perhaps a WWW database account), but don't want him to be able to log in, you can specify /bin/false as his shell (as is usually done with the nobody account). The shell can also be a program that runs when the user logs in, but it would be the only thing the user could do—exiting the program would log him out. If you choose this option, be aware that some programs allow users to start a shell from within the program. If the program “shells out” to a true shell, then the user has a back door into the system.
A complete discussion of shadow files is beyond the scope of this article. However, just to give you some idea of what they are and why they were created, I offer the following. The /etc/passwd file is “world” readable; anyone can make a copy of it. “So what,” you say, “the passwords are encrypted and can't be used.” Not true. Most users, in particular those who choose their own passwords, choose passwords that can be guessed or broken by a “dictionary attack” --that is, by using a program such as cops, an attacker can run a dictionary through crypt using the seed from the password to see if they get a match.
When the shadow file is used to maintain passwords, it is not world readable and cannot be copied off the system. An “x” in the password field tells you that this system uses shadow passwords. The shadow file also contains information about when the password was last changed, if the user will be forced to change it and how often (password expiration date), etc. Periodic forced password changes reduce risks posed by users who do not guard their passwords well.
Most recent Linux distributions include the PAM (pluggable authentication modules) libraries. PAM doesn't require applications to be “PAM aware” in order to function correctly, but these are only libraries and do require programs written with them. The shadow suite requires numerous programs to be recompiled or replaced with shadow-aware applications. If you need this kind of security, you need to do some serious reading.
The /etc/group file is also a colon-separated list consisting of only four fields: group name, group password, GID and members. The group name/password pair works the same as the /etc/passwd file. However, groups usually don't have passwords associated with them. A quick look at your /etc/group file will reveal the second field doesn't have an entry. Adding passwords to groups doesn't normally enhance security, since users are even more lax about group passwords (why not, everyone knows it) than their own.
The original group implementation in Unix allowed a user to belong to only one group at a time, and they changed group if required. Now, belonging to several groups at a time is common, so this has little relevance in most situations. Files are saved as the users' primary group, but can be changed manually using the chgrp command or via the setgid bit on the directory. The third field is the group-identification number and is functionally equivalent to its /etc/passwd UID counterpart. The fourth field consists of a comma separated list of group members (no spaces are used following the comma).
One last note on the /etc/passwd and /etc/group files. Several distributions I've worked with lately have been adding a line to the bottom of the file like this: +:::::: (The /etc/group file will only have four colons.) This line is added so that NIS databases are appended if no matching entries are found for user/password pair. This must be the last line in the file. Entries following this line are not read. I highly recommend that if you are not using NIS, you delete this line and use chmod to change permissions on ypbind so that it is not executable. If you run ypbind without a properly set up NIS server and the proper databases, you are vulnerable to someone who can trick your machine into binding to his server and reading his NIS maps to gain unauthorized access to your system.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
1 hour 17 min ago
- seo services in india
5 hours 48 min ago
- For KDE install kio-mtp
5 hours 49 min ago
- Evernote is much more...
7 hours 49 min ago
- Reply to comment | Linux Journal
16 hours 34 min ago
- Dynamic DNS
17 hours 9 min ago
- Reply to comment | Linux Journal
18 hours 7 min ago
- Reply to comment | Linux Journal
18 hours 57 min ago
- Not free anymore
22 hours 59 min ago
1 day 2 hours ago