Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 3 down vote favorite

I have a script that I want some of my users to be able to run that requires admin. Of course I don't want to give them admin privileges. How do I allow this script to run in a secure way?

Update: This is a Ubuntu 9.10 system.

share|improve this question

4 Answers

up vote 2 down vote accepted

Just use sudo. You need to configure sudo in /etc/sudoers, something like this:

fred ALL = (root) NOPASSWD: /path/to/command

Replace fred with the username, or use %group for a group. If you remove the NOPASSWD: option then they will be prompted for their password each time.

setuid on a script is insecure and won't work on Linux.

share|improve this answer
Thanks, I didnt know sudo was this versatile. Maybe you could update your answer with more specific instructions for people that have this question in the future? – Seamus Jan 25 '10 at 19:11
Sure, I've updated it with an example. – James Jan 25 '10 at 19:22
1  
Just be wary of anything run by the script that allows access to a shell escape - such as vi/vim. – Jonathan Leffler Jan 26 '10 at 5:24
up vote 1 down vote

sudo and SUID are both very insecure. It's possible - and, depending on the scripting language, easy - to escape out of either of them. SUID is by far the worst, and some scripting languages won't even run if that's done.

I have a blog post on how to do it securely, which I first wrote for running Nagios check plugins as root but is perfectly applicable here. There's a small C program (that's been floating around the Linux admin world for years) that just acts as a wrapper around the script. You just edit the C program source to include the full path to the script, compile it, and then set that SUID (or give sudo access to that). The source is on my site: setuid-prog.c.

The inherent problem with running scripts as root (for non-root users) is that in many languages, using a variety of techniques (from poor input checking to overflows) it may be possible to break out of the running script and get full root access. Many old-time Unix guys recommend just writing a C program to do what you need - but then again, most of them were SAs when you needed to be able to write C competently.

share|improve this answer
Very interesting. Its not really a problem in my case because I trust my users with root, they just don't have the skill to use it properly. Thanks for the information though. Have you ever used the shc script compiler? Edit: Wouldn't it be possible to modify the data section of the executable and replace the #defined path with whatever you want? – Seamus Jan 26 '10 at 16:41
Nevermind. For some reason I spaced that the executable would be read only to the user. – Seamus Jan 26 '10 at 16:49
up vote 0 down vote

On which OS?

On Linux/Unix you can allow them to run it via sudo. The /etc/sudoers file can be modified to grant them specific permissions on designated commands, to certain IDs (users).

Alternatively, you can set the SUID bit on it, and change the script to be owned by a privileged user. That would set the script to run as that user, rather than the user running it. However, that is for all users running it.

share|improve this answer
2  
Shouldn't and/or can't setuid on scripts. – Dennis Williamson Jan 25 '10 at 18:59
Well, that's why my preference would be sudo, which is designed for the task. SUID is a bit (very) messy in this case, giving waay more access to everyone. And, potentially someone can change the script and run anything with elevated permissions. – Alex Jan 25 '10 at 19:48
up vote 0 down vote

There are two ways:

The best is to set the SUID bit on it: chown root yourscript; chmod a+s yourscript.

Alternatively, you can give them access to modify it using sudo, by running visudo and following the instructions. However, this is unnecessary, as this works by them running sudo, which has the SUID bit.

share|improve this answer
1  
Shouldn't and/or can't setuid on scripts. – Dennis Williamson Jan 25 '10 at 19:00
I didn't know this before - please can you eloborate? – fahadsadah Jan 25 '10 at 20:08
1  
It is long-standing advice; it may be less critical now than it used to be. Basically, there are (and definitely were) too many ways of subverting a script. Infamously, one way was to set IFS="/" (and ensure that PATH was set appropriately); this made it easy to execute commands that the script writer did not expect, especially annoying if they'd gone to the effort of specifying /bin/rm and so on. That no longer works; there are likely to be other equivalent but more devious ways to subvert scripts. Be extremely cautious! – Jonathan Leffler Jan 26 '10 at 5:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.