3

I want to be able to give a user on a system I administrate the ability to access file X, using command Y using sudo.

Is there a way to do this while allowing some flexibility over the arguments to command Y?

The following:

user ALL=NOPASSWD: /usr/bin/X /path/to/Y

Will allow the user to run X with Y as its only argument, but what if I wanted to allow the user to supply some optional arguments to X?

This:

user ALL=NOPASSWD: /usr/bin/X * /path/to/Y

Wouldn't be secure, as the the user could use the wildcard to to pass additional file arguments to X. I'd need something more restrictive.

Can I do this simply with sudo? Or do I need to use a different method?

2 Answers 2

9

Make a wrapper command that specifies the particular command line arguments and then give the user sudo access to that.

3
  • 1
    +1: a wrapper script is usually the easiest and least error-prone approach to this problem. Another approach, if you are determined to do it entirely within sudo, is to use globbing - search for "Wildcards" in the sudoers man page and read carefully. Jul 27, 2009 at 15:41
  • @Paul: If you think it can be done with wildcards, why not post an answer with an example? I don't think wildcard are restrictive enough to be safely used. Jul 27, 2009 at 15:53
  • 1
    FWIW, if I was doing this myself I'd probably use a Perl wrapper and explicitly parse the supplied parameters and crap out if any invalid parameters (or extra filenames) are supplied.
    – Alnitak
    Jul 27, 2009 at 16:14
0

One alternative to sudo for this use-case, or enhancement/addition, is to use UNIX file system permissions, extended file system ACLs, or SELinux.

For example, you could create a user or group which has access to precisely that file, and either

  1. just add the user to that group (if managing that file with any command is fine),
  2. let the user "become" that user (or group?) instead of root for that command,
  3. create a copy or wrapper of that specific command with that user or group as the owning user or group (instead of root), and set the SUID or SGID on it (but take away that same user's/group's write permission to the copy/wrapper program), or
  4. use the SELinux equivalent of SUID/SGID: configure the executable (or a copy/wrapper of it) to automatically change SELinux context when executed, to a context which has the right permissions to just that file.

Each of these approaches is simpler and more direct than a sudoers line and/or an argument-interpreting/manipulating wrapper command for precisely expressing the intended setup.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .