SCALE: For our readers who aren't familiar with you, can you share a little about your background?

Todd Miller: I've contributed to various Open Source projects since the early 90s including Sendmail and ISC cron. I've been a member of the OpenBSD project since 1996, focusing primarily on the userland libraries and utilities. In a former life I was an upstream maintainer for the SELinux toolchain. I'm probably best known for maintaining Sudo for the past 18 years.

SCALE: What is your current role in the sudo project and how long have you been involved with it?

Todd Miller: I've been hacking on sudo since the early 90s. I made my first public release in 1994 and have been de facto project lead ever since.

SCALE: For those who are unfamilair with sudo, can you provide us with a quick overview of what it can be used for?

Todd Miller: Sudo allows users to run commands as another user, typically root, without having to start a shell as that user. The file that controls which users are allowed to run what commands is called the "sudoers" file. On a multi-user machine (or groups of machines), sudo can be used to delegate sets of privileged commands to system administrators or trusted users. On a single-user workstation, sudo is often configured such that the user can run any command.

SCALE: What type of contributions has Quest made to sudo?

Todd Miller: Quest has sponsored development of the loadable module support in sudo (see below) as well as much of the I/O logging support. As part of my full-time job, 50% of my time is allocated to working on sudo. This has made it possible to devote more time to some of the important (though less exciting) tasks that sometimes fall by the wayside such as release engineering and packaging, bug triage and the development of unit and regression tests for sudo.

SCALE: You will be presenting at SCALE later this week on new developments in the 1.8 release of sudo. What would you say is the killer feature of this new release?

Todd Miller: The "killer feature" in sudo 1.8 is dynamically loaded modules. This makes it possible for third parties to write sudo plugins that implement custom security policies and logging of command input and output. There are a number of root access control packages out there, both Open Source and commercial. The plugin support makes it possible for users accustomed to using sudo to continue using it even if they want/need to use different security policy for root access. All that is required is a plugin that can assess the security policy and determine whether the user is allowed to run the command.