FreeBSD basics – 2 – Users & Groups

In the last post, we’ve initially configured FreeBSD so that networking is up and running, additional packages can be installed, and the system was patched to the latest release. In this post we’ll look at how users and groups are managed in FreeBSD and what FreeBSD provides when it comes to additional security mechanisms.

On Linux systems users are usually created with useradd, and groups are created with groupadd. There is also usermod and groupmod, which are used to modify users and groups. With FreeBSD you can do all those tasks with pw, no matter if you want to manage users or groups:

By giving the “help” switch to a sub command you may easily check the syntax (or read the man page, of course):

A typical group would be created like this:

A new user with that group as the primary group would be:

Another option you have is adduser. This is basically a wrapper around “pw” and gives you an interactive way of creating users:

adduser also created a new ZFS file system for the new user (this did not happen with pw, and this is only done when the parent of the home directory is also ZFS):

All those defaults can be controlled, as you can ask adduser to create a template:

This created “/etc/adduser.conf”, which will be the template for new users created with adduser:

So far there is nothing special, the commands are not the same as on Linux, but the concepts are very similar. What you might have noticed is, that there is something which is called a “login class”. Login classes are used to setup users environments and optionally put restrictions on resource usage. Those classes are defined in “/etc/login.conf” and the default class looks like this:

There are many more examples in that file, take your time and have a look at them to get an idea. If you change something in that file, you’ll need to re.generate the database with “cap_mkdb“. There is the same concept for the password files. If you check “/etc/master.passwd” you see the hashed passwords (in Linux it is /etc/shadow), but if you check “/etc/passwd” there are no hashes anymore:

The reason is that normal users are not allowed to read “/etc/master.passwd” but still can get basic account information out of “/etc/passwd”. So there needs to be a way to generate the second one out of the first one, and this is done with “pwd_mkdb“. In the same way as “cap_mkdb” does it for the login classes, this one does it for the password databases:

The result are binaries and faster to process than the text representation of the base files. In addition the “/etc/passwd” file is created out of the master file without the sensitive information.

Let’s do a simple test show how this works. The password database files currently have these timestamps:

Changing the shell of “user2” using “pw” will update all the files at once:

On the other hand, if we change the shell of “user2” back to bash manually in “/etc/master.passwd”:

… the other files have not been touched and still show the old timestamp:

In this case we need to run “pwd_mkdb” manually to get this done:

At least from my point of view it is not advisable to do it like this. If you want to edit users manually, instead of manually editing the master file you should use “vipw“. This at least does some sanity checks for you and is automatically rebuilding the password databases. Otherwise us “pw” or “chpass“.

The final topic for this post is something that very much reminds of PostgreSQL’s pg_hba.conf, which is called “login access control table” in FreeBSD. As in PostgreSQL, you can define who, from where, networked or not, is either accepted to login or not. Have a look at “/etc/login.access” to get an idea how that looks like. Here are some examples from that file:

That’s it for today. In the next post we’ll look at services are managed in FreeBSD.