Introduction

This assignment will extend a basic implementation of “zones” in the OpenBSD kernel. The main area of improvement will be separating group and user permissions on zone operations. You will be provided with a diff that adds the basic zones functionality to OpenBSD. You will need to make changes and improvements on top of this diff. The purpose of this assignment is for you to demonstrate an understanding of the role of an operating system kernel and how it supports processes making system calls, as well as your skills in reading, understanding, and modifying existing code.

Zones extend the isolation of processes beyond what is traditionally provided by UNIX and UNIX-like systems, including OpenBSD. Traditionally, all processes running on an OpenBSD are visible to all other processes. This can be demonstrated by running commands like top(1), ps(1), and pgrep(1)/pkill(1), which can show all processes running in a system.

While all processes are visible to each other, they are restricted from interacting with each other based on the user that each process is running as. A non-root user can only signal their own processes. Attempts to signal processes running as another user fails.

Zones Implementation

Zones are implemented for this assignment to add further isolation of processes. Processes running within a zone can only see and interact with processes running within the same zone, regardless of which user within the zone is running the commands. This implementation is loosely modelled on the design of Solaris Zones as described in PSARC/2002/174. The exception to this enhanced isolation is for processes running in the ”global” zone, which is the default zone that is created and exists on boot. Processes running in the global zone can see all other processes in the system, including those running in other (non-global) zones, and the root user in the global zone can signal any of these processes too. However, non-root users in the global zone cannot signal processes in other zones, even if they are running as the same user. The provided diff implements changes to the kernel and several userland utilities and adds a zone(8) command and man page. The zone(8) command provides several sub-commands that expose the functionality of the kernel zone subsystem.

You will be adding additional functionality to a series of zone(8) sub-commands, adding three new zone(8) sub-commands, and implementing any necessary changes to the kernel zones system to support them. Your additional functionality centers around zone permissions. Files have an associated “user” and “group”, and this user or group may have permission to operate on the file. Your task is to associate zones with a particular owner and group, and allow the owner of the zone and users who are in that group to perform operations on the zone (regardless of whether they are the owner of the zone). In short, where zones are now only controllable by root, your changes will allow the owner of a zone and a different group of users to control a zone. The additional sub-commands you will be implementing are: zone rename, which will change the name of a zone; zone chown, which will change the owner of a zone in a manner similar to the existing chown(8); and zone chgrp, which will change the group of a zone in a manner similar to the existing chgrp(8).

Instructions

As you add the functionality specified in the next sections, some of these steps will be repeated. eg, changing the kernel means rebuilding and installing the kernel. Adding a syscall means making the syscall stub as a function visible in the headers (make includes), and callable through libc.

We have over-specified the errors you should return from your syscalls - if you do not require an error code (for example, never returning ENOMEM on memory failures because you never allocate any memory) then you do not have to use it. The reverse is also true - if you find an error case that is not listed, choose an appropriate error from errno(2). We will not explicitly test all errors, but during your code interview, we will expect you to be able to explain the suitability of the error codes you use.