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!)
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
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
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:
/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).
exec in the shell script instead of just calling the command directly? (I'm not saying that it's wrong, I just like to know why you'd do it so I can maybe learn something)
exec, the called command will substituted in the place of the shell. The shell will go away. Without an exec, the shell will start that command, and then waits its termination, and then exits. This second, exec-less means multiple cooperating processes, which is unneeded. But there is no big difference, without exec would this work just so well as with that.
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.
You don't want to use sudo to grant root for some commands. Instead you could chmod 4750 a specific program [that can wrap the command], to elevate the rights of a normal user to execute that as root.
sudois for. What are your business objections to his usingsudofor this?sudo. What are the objections?sudo, then? Or passworded sudo to run the DNS management tool, which can then operate withnamedgroup or user privilege, or root privilege, as needed.sudo. In trying to express it to us, he may either clear up our confusion, or his own - or both!