Giving access of a set of commands to a non-root user without sudo

I want to give non-sudo access to a non-root user on my machine, there is a user dns-manager, his only role is to run all the BIND commands(rndc, dnssec-keygen) etc.

Now everytime he has to run a command, he types,

sudo rndc reload

Is there a way I can get rid of this sudo, but only on a particular set of commands(and only for dns-manager)?


If I understand your comments correctly, the issue here is that the command will be issued through a connection that does not have any ability to enter the password that sudo defaults to requesting. Also, in many OS distributions, sudo will default to requiring a TTY - which this program may not have.

However, sudo is able to have a very fine-grained permissions structure, making it possible to allow one or more users to issue one particular command without password and TTY. Below, I'll show three ways to configure this for your needs. Whichever one you choose, the user will now be able to issue the command sudo rndc reload without having to enter a password.

(Also, this may be unnecessary, but... please remember to make a backup copy of your sudoers file before editing it, to keep a shell where you're root open in case you need to revert to the backup, and to edit it using visudo instead of sudo vi /etc/sudoers. Hopefully these precautions will be unnecessary, but... better to have them and not need them than the reverse!)

1. If you don't want to require a TTY for any requests

The easiest way to get rid of the TTY requirements (if one exists) is to make sure that the line beginning with Defaults in /etc/sudoers does not contain the word requiretty - instead, it should contain !requiretty. However, if you do this, it means that no sudo command will require a tty!

You will also need to add the line

rndcuser ALL = (root) NOPASSWD: /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program

2. If you want to require a TTY for all users except this one

This can be done by setting a default for this one user, like this:

Defaults:rndcuser        !requiretty
rndcuser ALL = (root) NOPASSWD: /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program

3. If you want to requre a TTY for all commands except this one command by this one user

This is a bit more complex, due to the syntax of the sudoers file. You'd need to create a command alias for the command, and then set a default for that command alias, like so:

Cmnd_Alias RNDC_CMD = /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program
Defaults!RNDC_CMD !requiretty
rndcuser ALL = (root) NOPASSWD: RNDC_CMD

Yes. sudo can be configured very flexibly. Even so, I must mention: these types of solutions shouldn't be considered very secure, and they should only be used in a cooperative environment where other controls are on place (thus, you can give these enhanced privileges to your loyal subordinate, but shouldn't do so for a customer you know only from the net).

The sudo config is in /etc/sudoers in most systems. You can find out its syntax by Googling or by a man sudo command.

You shouldn't edit this file directly; doing so can lead to security race conditions. Instead, use the visudo command (which is a wrapper around your $EDITOR environment variable).


After you configure sudo, you can easily wrap this around the visible commands. It is very simple:

  1. Create a directory for a list of your sudo wrapper scripts (f.e. /usr/local/dnsadmin/bin)
  2. Create a wrapper script for the commands you want them to make usable without sudo. It will be a very simple command, for example, /usr/local/dnsadmin/bin/rndc will be:

    #!/bin/bash exec /usr/bin/sudo /usr/sbin/rndc "$@"

  3. Get this directory into their PATH environment variable (e.g. by a system-wide or their local .profile).


While this isn't a general solution in the specific case of rndc you don't need sudo at all.

rndc can communicate with any named process either via a local socket or a remote port, using a secret key to authenticate itself. By default (or at least, for debian, which is the distro I use) this file can be found in /etc/bind/rndc.key and is normally readable only to user bind and group bind.

Anyone who has read access to that key file (or an identical copy of it) can use rndc to control the BIND server, so the easiest solution in this particular case would be to add the user to the bind group.

A surprising number of common daemons have something similar set up (I'm personally still figuring out the possibilities of powerdns in that regard, but it's looking promising so far). If you don't want to do sudo you'll have to check whether what you want to accomplish is possible on a case by case basis.