JSP Web Hosting Blog

Groups of Users UNIX classifies users into groups, each group consisting of people who perform similar administrative functions. A sysadmin can define a group called “www,” add the people who edit web pages to that group, and give that group permission to read and write to web-related files. He could also create a group called “email,” add the email administrators to that file, and set permissions on mail-related files so that users in that group can edit those files. Using groups in this manner is a powerful and oft-neglected tool for systems management. What Groups Are You In? Any user can identify the groups he has been assigned to with id(1). This command tells you which user you are logged in as and which groups you belong to. It also prints the numerical identifiers for your user ID (uid) and any groups you are assigned to (gid). # id uid=1000(mwlucas) gid=1000(mwlucas) groups=1000(mwlucas), 0(wheel) # If you are one of those lucky users who may use the root password to become the superuser, id(1) will tell you if you have done so and are in a root shell. (If you’re running several X terminals on a UNIX desktop, it’s quite easy to forget which window has your root shell in it.) # id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) # As you can see, root is a member of several groups by default. id(1) has several options, but they trim the output rather than provide additional information. If you want to only know the names of the groups you’ve been assigned to, for example, you could use “id -Gn”. While this is useful for scripts, id’s output is small enough that most people find it easier to skim the output for desired information than remember the options. The id(1) command pulls this information from /etc/group. /etc/group The file /etc/group defines most group information. While the syntax of this file is fairly easy to understand, OpenBSD also provides some command-line tools to edit it. I generally find the /etc/group syntax simple enough to handle that I skip the command-line tools. If you’re interested, the command-line tools are groupadd(8), groupdel(8), groupinfo(8), and groupmod(8). In most cases, it’s just as easy to edit /etc/group directly. Each line in /etc/group contains four colon-delimited fields: the group name, the group password, the group ID, and a list of members. Here’s a sample entry: 1 wheel: 2 *: 3 0: 4 root,mwlucas,chris The 1 group name is a user-friendly name for the group. In our example, the group is named “wheel.” Group names are fairly arbitrary: You could call a certain group of users “bucksnort” if you wished. It’s a good idea to choose group names that give you some idea of what they’re for; while you might remember that the group “bucksnort” is intended for email system managers, will your coworkers understand that? Choose group names that mean something. The 2 second field contains the group’s encrypted password. Group passwords encouraged poor security practices, so most modern UNIXes don’t support them. OpenBSD certainly doesn’t do anything with group passwords. Some old software expects to find a password field in /etc/groups, however. Rather than leave this field blank or remove it entirely, we use an asterisk (*) as a place-holder, as in our Page 137
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

Full Name: Chris B. Office Location: Office Phone: Home Phone: You can make any changes you need here, and they will be reflected appropriately in /etc/master.passwd and /etc/passwd. Chpass(1) doesn’t change anything except those files. This means that if you move an account’s home directory in chpass(1), you’ll need to manually move the actual home directory. Otherwise, the user will get an unpleasant surprise when they try to log in! User Editing Caveats On OpenBSD systems, /etc/passwd is automatically generated from /etc/ master.passwd via pwd_mkdb(8). Tools such as chpass(1) and vipw(8) do this automatically. If you’re familiar with UNIX versions that allow you to directly edit /etc/passwd, you need to retrain yourself when working on OpenBSD. Not only is your chance of making a mistake high, but your changes will be overwritten the next time someone uses a standard tool to change user information. Page 136
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

Removing User Accounts Part of any security policy is the timely removal of user accounts. You can do this with rmuser(8). It will ask me to confirm both the account name and that I want to delete the user’s home directory. Rmuser will also delete any cron jobs belonging to the user, as well as that user’s mail spool. For example, if Chris no longer has access to the system, I can delete him like this: # rmuser chris Matching password entry: chris:*:1002:1002::0:0:Chris S.:/customers/chris:/usr/local/bin/tcsh Is this the entry you wish to remove? y Remove user’s home directory (/customers/chris)? y Updating password file, updating databases, done. Updating group file:Removing group chris — personal group is empty done. Removing user’s home directory (/customers/chris): done. # Editing Users OpenBSD supports the classic vipw(8) tool that allows an administrator to directly edit /etc/master.passwd, but for most cases chpass(1) will do everything you need in a much more friendly way. The only real need for vipw(8) is if you have damaged the password file somehow. Any shell user can use chpass(1) to edit their own account information. You might not want to allow users to do this, however, as one piece of information that chpass(1) allows them to alter is their hashed password. Many regular users are not equipped to recognize a hashed password; I’ve seen people whom I believed Should Have Known Better try to change their password by entering it in the hashed password field. This locks them out until a sysadmin resets their password to a known value. While you might expect that an ignorant user would be intimidated by that long string of garbage, and hence decide to not touch it, that doesn’t seem to be the case. I have yet to see anyone who is not intimidated by it a second time, however! As chpass(1) also allows them to change things such as their phone number and office location, however, you frequently cannot get away with disallowing use by regular users. As root, you can edit any user’s account information by running “chpass username.” This brings up a text editor that displays the account information from /etc/master.passwd. For example, if I run “chpass chris” as root, here’s what I get: Changing user database information for chris. Login: chris Encrypted password:$2a$06$3M22I/s4FC8Mv80Q00sPRed9KhzIUUrBD17pOW66TK.BInzP Uid [#]: 1002 Gid [# or name]: 1002 Change [month day year]: Expire [month day year]: Class: Home directory: /home/chris Shell: /usr/local/bin/tcsh Page 135
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

. The full name cannot contain a colon (:). . The user’s shell must be listed in /etc/shells. [1]Mind you, this is an absolutely hideous password, for an extraordinarily wide variety of reasons. But if you’re interested at all in security, you know that already. [2]Technically, you could create a username that contained any character you liked or even multiple identical usernames but then you run into all sorts of potential problems. Stick with the defaults unless you know exactly what you’re doing and are prepared to deal with the consequences. Page 134
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

ma nd line bef ore the -ba tch co m ma nd. Th e -ba tch co m ma nd tell s ad du ser tha t wh at foll ow s is the act ual ac co unt info rm ati on. The -noconfig option tells adduser to not read the default /etc/adduser.conf. Using this in a script is an excellent way to make sure administrator-friendly settings in /etc/adduser.conf do not leak into regular user accounts. The -dotdir option specifies a nonstandard directory where user dotfiles are stored. All files in this directory will be copied to the user’s home directory. -home tells adduser which directory to create a new users’ home directory in. This is not the actual home directory, but rather the directory where the home directory will be placed. For example, if all of your web server customers have home directories on the /www partition, you might use -home /www on the batch adduser command line. Account Limitations A user account is subject to the following restrictions. . Usernames can contain only lowercase letters, digits, dashes, or underscores. [2] Page 133
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

Chris’s account to really have a password of “loser1,” I could enter this: # adduser -unencrypted -batch chris wheel ‘Chris B.’ loser1 The user now actually has a password of loser1. [1] You might use this inside a script, or at some time when nobody is around to look over your shoulder. Generating Pre-hashed Passwords If you’re using this within a script, you probably want to pre-generate hashed passwords. Encrypt(1) does this. By default, encrypt just gives you a blank line. When you enter a word, it returns the Blowfish-hashed password. You can enter any number of words, and each will be hashed separately. Hit CONTROL-C to exit encrypt. # encrypt loser1 $2a$06$RdxEtB0DNJ6MY67j77m/Bu.JYydNnErTo2cAV0InHg5gkCK1JrbBC ^C # If you’re just doing one password or using this interactively, you probably want to use encrypt’s -p option. This gives you a non-echoing prompt for a word to be hashed. # encrypt -p Enter string: $2a$06$RHWwSGRFSat8byeBcm6W6.H9LKC7Cxi8A2pjqC0hUi8LfHtV6OeQK # Between these three choices, you should be able to handle passwords in adduser’s batch mode in any way you desire. Other Adduser Batch Mode Options When running adduser(8) in batch mode, you have several other options to override the default configuration. I will frequently set up administrator accounts in one way and user accounts in another, and use different tools to create each. Frequently, sysadmin accounts are created in adduser’s interactive mode I don’t have many systems administrators on any given system. Someone else running a script that I’ve written creates user accounts on a routine basis. You can get a complete list of adduser options by reading adduser(8). These are simply the options I find most useful. No All te of the se opt ion s mu st ap pe ar on the co m Page 132

Hint: This post is supported by Gama web hosting hrvatska services

shellpref = (’csh’, ’sh’, ‘ksh’, ‘nologin’) This is a list of legitimate shells. Adduser will let you choose from any of these when creating a new user. defaultshell = “csh” This is the default user shell. It can be any of the shells listed in “shellpref.” defaultgroup = USER This is the primary group that the user is a member of. Traditional BSD systems assign each user to a group of the same name as the username. For example, our “phil” user is automatically a member of the group “phil,” which was created just for him. You might want all users to be part of a separate group, such as “students” or “customers.” If that’s the case, you can set that on this line. You can add this user to other groups manually, but this will be the primary group. uid_start = 1000 uid_end = 2147483647 These give the range of acceptable user ID numbers, or uids. The default is fine for most cases, but you might want to use different numbers to interoperate with your other UNIX-like systems. Adding Users Non-Interactively You might need or want to add users in a single, longer command. This is common if you have scripts or cron jobs that add users at regular intervals, for example, or if you’re comfortable with remembering long commands with many options. Adduser’s -batch flag enables this. When you use this mode, adduser takes four additional arguments: the username, the group name, the full name, and the password in encrypted format, much like this: # adduser -batch chris wheel ‘Chris B.’ loser1 Here we create a user account for Chris, put him in the wheel group, and give him a password that encrypts to the string “loser1″. Passwords and Batch Mode If you actually follow the previous example, you’ll create the account without a known password! Remember, no modern UNIX stores its passwords in readable format; instead, it stores a “hash” of the password. If you take the password and perform some horrible computations on it, you’ll create a hash. When you create or change a password, the system creates this hash and stores it in /etc/master.passwd. When you attempt to log in, the login process takes your password, generates a hash, and compares the hash of the offered password with the hash in the password file. If the hashes match, exactly, the login is permitted. The example above creates an account with a password hash of loser1, not a password of loser1! This isn’t even a legitimate hash, and no entered password will match it. Most of us cannot calculate Blowfish hashes from known text in our heads; we either need pre-generated encrypted passwords, or we need to enter unencrypted passwords on the command line and have adduser do the calculation for us, or we must create an account with no password at all. Creating an account without a password is perhaps the simplest option. The account is disabled until you go back and enter a password, but this may be acceptable for accounts used to run daemons and services. Simply run adduser in batch mode, omitting the password. # adduser -batch chris wheel ‘Chris B.’ If you want to enter an unencrypted password on the command line, you can do this with the -unencrypted option. Be sure you put this option before the -batch option! For example, if I wanted Page 131

Hint: This post is supported by Gama web hosting hrvatska services

All new user accounts get a set of default shell dotfiles. You can use the ones that OpenBSD provides in /etc/skel, or you can create your own customized for your environment. Any files in this directory will be copied to the user’s home directory, so you can also use this to distribute any other files you like. Be sure that regular users cannot put “extras” in a directory you specify! send_message = “no” On many operating systems, new users automatically receive a welcome or instructional email message. By default, OpenBSD does not do this. If you put the full path to a file in this variable, however, the contents of that file will be emailed to each new user. If you set this to no, a message will not be sent. OpenBSD does have a default new user message in /etc/adduser.message, but you should feel free to create your own. The adduser message accepts the variables $username and $fullname; this allows you to customize your welcome message somewhat. (If you’re familiar with Perl, you can add your own variables by editing /usr/sbin/adduser.) If you wish, go ahead and create your own message instead of using the brief and generic default. I generally use an /etc/adduser.message.local somewhat like this: $fullname, Welcome to The Company. Help is available at 800-555-1212, or online at http://helpdesk.companyname.com. Use of this account is governed by our acceptable use policy, available at http://www.companyname.com/aup.html or on this system in /usr/local/share/company/aup. Thank you for your business. We look forward to serving you. The Company Support Staff. logfile = “/var/log/adduser” Adduser will record the history of its actions in the file specified here. home = “/home” This variable controls the directory where users’ home directories are located. This is one of the first things I take care of on any OpenBSD system. If you do not specifically create a /home partition, the default will place users’ home directories on the root partition. This is bad, for a variety of reasons. The biggest problem in that your root partition is limited to 8GB in size, which greatly restricts the amount of user data your system can hold. If you expect to have a lot of user accounts on your system (i.e., for a web server), you almost certainly want a /home partition so you can mount it with the appropriate permissions. If you only have systems administrators accounts on this system, you might want to place user accounts under /usr/home and create a symlink from /home. Both work, but you should know about your choices. path = (’/bin’, ‘/usr/bin’, ‘/usr/local/bin’) This contains the list of directories that can contain legitimate shells. This covers most standard situations, but if you find that you’re installing shells in some unusual location, you’ll want to edit this appropriately. Page 130

Hint: This post is supported by Gama web hosting hrvatska services

Adduser(8) will prompt you for an initial password and then show you your new user so you can double-check your work. Each field you entered previously is displayed for your approval. Enter password []: Enter password again []: Name: phil Password: **** Fullname: Philip C. Uid: 1001 Gid: 1001 (phil) Groups: phil HOME: /home/phil Shell: /bin/csh OK? (y/n) [y]: At this point, you can cancel the whole thing by hitting “n.” If the account looks correct, however, you can hit “y” and let adduser create the user. Added user “phil'’ Copy files from /etc/skel to /home/phil Finally, adduser will ask you if you want to create a second user. You can do that if you wish, or not. Add another user? (y/n) [y]: n Goodbye! # Congratulations! You have added a user to your system. Now that you know how the process works, let’s take a look at customizing and configuring adduser(8) to give it the defaults you want. /etc/adduser.conf The first time you run adduser(8), it uses your answers to build its configuration file, /etc/adduser.conf. Value assignments in this file control adduser(8)’s behavior. If the variable has multiple legitimate values, those values are surrounded by parentheses. Without further ado, here are the standard things you may set in /etc/adduser.conf. To get a complete list of things that may be set in adduser.conf, you’ll need to read the adduser script. verbose = 1 The verbose flag tells adduser how much detail to give. If you have a verbose of 0, adduser(8) will only present a minimum of information when run. It will assume that you know it is checking the user files in /etc/, for example, and hence not bother to tell you about them. The standard is 1. If you want to debug the adduser program itself, you can set this to 2 for maximum debugging output. I habitually turn this to 0 without a second thought. encryptionmethod = “blowfish” OpenBSD supports a variety of encryption schemes for encoding passwords. Blowfish is the OpenBSD standard. If you want to share your password file with other UNIX-like operating systems, though, set this to “old” to get DES hashes. dotdir = “/etc/skel” Page 129

Hint: This post is supported by Gama web hosting hrvatska services

Adding Users OpenBSD uses many of the standard UNIX password-management programs, such as passwd(8) and vipw(8). OpenBSD also includes a friendly interactive user-adding program, adduser(8). We’ll cover that program first and then go on to some of the other tools for more advanced uses. Adding Users Interactively If you start adduser(8) at the command line, without specifying any options, it drops you into an interactive shell. The first time you run it, it will ask you a series of questions to determine its default settings. It will save these settings, but don’t worry too much; we’ll look at how to change your defaults later. You must have root privileges to run adduser(8). # adduser Use option “-silent'’ if you don’t want to see all warnings and questions. Reading /etc/shells 1 Check /etc/master.passwd 2 Check /etc/group 3 Ok, let’s go. Don’t worry about mistakes. I will give you the chance later to correct any input. Whenever adduser starts, it checks the user configuration files. Vital information is kept in 1 /etc/shells, 2 /etc/master.passwd, and 3 /etc/group. Once adduser is convinced that your user configuration files are not corrupted, it will give you a chance to enter the username you want to create. You’ll see in brackets the legal characters for usernames in OpenBSD specifically, any letter or number, plus the underscore and the dash. Enter username [a-z0-9_-]: phil Once you have that, you’ll get a chance to enter a real name for the user. Enter full name []: Philip C. Next, adduser gives you a chance to choose the users’ shell. The list of shells is taken from /etc/shells, with the addition of the “nologin” option. The default shell is shown in brackets. Enter shell csh ksh nologin sh [csh]: csh Now you can choose a uid (user id number). By default, OpenBSD starts numbering uids at 1,000 and takes the first available uid. You can change this if you wish, but it’s generally not necessary. Uid [1000]: Login group phil [phil]: By default, each new user is assigned to a group with the same name as his username. You can assign the user account to a different group if you wish. If you have other system groups defined and you want this user to be part of one of these groups, you can enter it here. If you want this user to be able to use the root password, add them to the wheel group. Login group is “phil'’. Invite phil into other groups: guest no [no]: wheel Page 128
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check Actions tomcat hosting services