Linux and macOS users are familiar with sudo, a programme that allows you to run a command as another user, usually root (the administrator). Although sudo can be installed on OpenBSD, doas is used instead, as it is part of the system.

Why I wanted to contribute to doas

When configuring doas via the /etc/doas.conf file, you can use the “persist” directive, which means you don’t have to re-enter your password for 5 minutes. This way, if you have several commands to enter, you don’t have to re-enter your password each time.

However, this 5-minutes timeout cannot be configured; it is a decision made by the OpenBSD team. And this is precisely an issue that comes up from time to time (such as here or there ), as some people would like to be able to choose how long the password is not requested again. Generally, these people would prefer a longer time, such as 15 minutes. Personally, I would prefer a shorter time, so that the password is remembered just long enough to type 2-3 commands, and then forgotten.

That’s why I decided to delve into the doas code and submit a patch to the OpenBSD team.

My doas patch

If you simply want to access the patch, it is available on Github .

The goal

To help you understand the change I have proposed, here is how doas is currently configured ( doas.conf(5) ):

# /etc/doas.conf

# Members of the "wheel" group are authorised to use doas; their password
# is stored for 5 minutes using "persist"
permit persist :wheel
# Newline required after a rule

Note: in my article about doas on OpenBSD Desktop , I mentioned that it was required to add a newline (\n) after each rule so that it is taken into account. Now that I’ve studied the parser, as well as knowing it, I understand why.

The patch I have developed adds an optional parameter to persist, allowing you to choose how many seconds the password is stored for:

# /etc/doas.conf

permit persist 60 :wheel
# Newline required after a rule

For 60 seconds, the user is not prompted to re-enter their password; this timeframe is shorter than the current 5 minutes. If the timeframe is not specified in the configuration, the default 5-minutes timeframe is used, meaning that this change is backwards-compatible: it adds a new feature without breaking the existing functionality.

How I did it

If you are thinking of contributing to OpenBSD, you might find this method of interest.

  1. OpenBSD uses CVS, but I prefer Git, so I cloned the repository from GitHub: git clone https://github.com/openbsd/src.
  2. As stated in the documentation , I have executed the following commands in the Git repository: git config diff.noprefix true and git config diff.renames false. This was useful when generating the diff file.
  3. which doas told me that the doas programme is located in the directory /usr/bin, so I’ve navigated to the correct folder in the repository : cd usr.bin/doas/.
  4. Once in the correct folder, I looked through the various files:
    1. doas.1 and doas.conf.5 are man pages, which can be viewed using man doas and man doas.conf.
    2. Makefile is the file that make uses to compile doas. make obj creates a subfolder called obj/, after which make compiles doas.
    3. env.c contains C code for managing the environment.
    4. doas.h and doas.c contain C code, the main() function is located in doas.c and is a good starting point for understanding how the programme works.
    5. parser.y is a rather special file, used by yacc . It defines the grammar used by the configuration file doas.conf; to add a configuration option, you need to edit this file. To do this, you’ll need to familiarise yourself with yacc, as it’s not just C code.
  5. After studying the documentation and the code, and making my changes, I generated a diff from the usr.bin/doas directory using the command git diff --relative . > doas-persist-timeout.patch.
  6. Finally, after reading the instructions , I sent an email to the mailing list with my patch attached.

The response from the OpenBSD team

A few hours after sending my message, I received a reply from Theo, the founder of OpenBSD, he didn’t like the idea of making the timeout configurable, and he put forward some good arguments. The 5-minutes timeout was chosen because it is neither too long to cause problems nor too short to be a nuisance, it keeps doas simple, without complicating configuration management.

A snub? Not at all. Of course I would have liked the patch to be accepted, but the explanation for the rejection makes sense, is consistent, and above all I learnt a great deal by digging into the code. And besides, I still have my patch, nothing stops me from using it even though it was rejected.

Understand the OpenBSD philosophy

OpenBSD is a system designed to be simple, having fewer features reduces the attack surface and the number of bugs.

Security is at the heart of everything: every feature added is considered from the perspective of security, risk and the complexity it introduces. A telling example is Bluetooth, which is deliberately not supported by OpenBSD.

In line with this focus on security is a commitment to writing correct code, and this is achieved through code reviews. Every patch is reviewed by other developers to identify any issues.

Advises to contribute

Here are a few tips if you’d like to contribute to OpenBSD:

  1. Read the documentation. This applies to users too. OpenBSD has excellent documentation: man 1 doas for the doas command, man 5 doas.conf to understand the doas.conf file, as well as man 2 pledge to find out more about the pledge system call, or man 3 getopt to access the documentation for the C function getopt.
  2. Communicate via the mailing lists . There are several of them, some for general discussion, others for submitting patches.
  3. Accept rejection. Whether on OpenBSD or another open-source project, developers are under no obligation to accept your proposals. That doesn’t necessarily mean they’re bad, though.

Conclusion

Contributing to OpenBSD is challenging, but rewarding. Even if the patch is rejected, the learning experience is invaluable, and getting as far as submitting the patch is a victory in itself.

Need an OpenBSD expert who knows the system inside out? Let’s discuss your project .