Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I need sudo for a command for any path under a particular area. Example:

sudo mycommand /opt/apps/myapp/...

What is the sudoers syntax to allow this command to run in any path that falls under /opt/apps/myapp? This is Solaris 10 sudo.


Thank you for your reply, but I don't need wildcards for the path to the commands, but wildcards for the arguments for the commands.

For example, we want to do something like...

sudo mycmd /opt/userarea/area1
sudo mycmd /opt/userarea/area1/area2
sudo mycmd /opt/userarea/area1/area2/area3

So far, using wildcards for the arguments in sudoers look like this:

/opt/userarea/*
/opt/userarea/*/*

And it seems like if we want to have N levels of directories, then we need N lines in sudoers! Is there a better way to include all N levels in one line in sudoers? Thanks.

share|improve this question

migrated from stackoverflow.com Apr 10 '10 at 0:34

This question came from our site for professional and enthusiast programmers.

1  
@CLee: you'll need to register an account here on Super User, then associate your Stack Overflow account via your profile -> accounts tab. email team@superuser.com if you need assistance. –  quack quixote Apr 10 '10 at 0:36

2 Answers 2

I was looking to do the same thing and found this (admittedly old) question...

As I researched further I found that the sudoers man page makes it clear that it will not match slashes in a wildcard match for a command/path name. From sudoers(5) (in the "wildcards" section):

Note that a forward slash (‘/’) will not be matched by wildcards used in the path name.

It doesn't say it in the man page but I think this is pretty clearly to keep someone with access to run commands in /opt/userarea/*from trying to run something like /opt/userarea/../../bin/sh which would obviously be bad...

So no, it won't work as you want (and as I wanted) -- by design.

share|improve this answer

Sudo is controlled by the file /etc/sudoers which tells it what it can and can't do. I don't know if you can achieve what you want to for the very reason I mentioned below, however, you can create a group of commands like so:

Cmnd_Alias TESTAPPS = /opt/dev/myapp/myapp1, /opt/dev/myapp/myapp2

You can then allow certain groups the ability to run sudo using just these commands. I have this set in mine:

root    ALL=(ALL)       ALL
%wheel  ALL=(ALL)       ALL

You could also add to that:

%development    ALL=(TESTAPPS)   ALL

Confusingly, the ALL in the first case indicates ALL hosts you are logging in from, so you can prevent sudo being run from certain hosts.

Just a quick warning - if you do this and enable write access to this area, the user can just copy commands from say /bin, /usr/bin or whatever and run what they like as root. So I could run sudo /opt/apps/myapp/rm -rf / and it would work. You also need to restrict where these commands can run.

share|improve this answer

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.