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:
- Create a directory for a list of your sudo wrapper scripts (f.e.
/usr/local/dnsadmin/bin
) -
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 "$@"
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.