mjhjmtu

I have a specific problem that has brought up some general questions.

The specific problem:

I have a sudoers rule applied to a group of somewhat restricted users. The rule in question is %pusers ALL=(ALL) NOPASSWD: /bin/vi /etc/httpd/conf/*. A user would like to cd /etc/httpd/conf and then sudo vi httpd.conf (or sudo vi ./httpd.conf). Currently sudoers does not allow this, but it will allow running vi against the absolute path: sudo vi /etc/httpd/conf/httpd.conf. I assume that the relative path is not being translated to the full path before sudo checks to see if it’s allowed, but I don't know exactly why or how I could work around this.

I'm specifically working with RHEL7 and have not tested this on other *nix systems, though I would expect to see similar behavior.

The general questions:

1. How does sudo handle relative paths passed to it on the execution side, like in the example above? (Not relative command paths, relative paths against which a command executes.)


2. How can one get sudo to recognize/translate a command's relative execution path when checking it against the sudoers rules?

Giving regular user sudo access to an editor like vi or vim is risky. See this question for an in-depth explanation.

With a modern version of sudo, you could specify in your sudoers:

%pusers ALL=(ALL) sudoedit /etc/httpd/conf/*

Then, your users could specify their editor of choice using the VISUAL or EDITOR environment variables (as usual), and then use

$ sudoedit /etc/httpd/conf/httpd.conf

or

$ cd /etc/httpd/conf
$ sudoedit httpd.conf

Instead of sudoedit, sudo -e could be used as well.

Modern sudo recognizes sudoedit as a command built-in to sudo, and when you use it, sudo understands that the arguments are supposed to be pathnames of files to edit (only), and then handling of relative pathnames becomes possible.

In a general case (= when not using the sudoedit keyword), sudo won't presume to know anything about the command parameters, so if you specify a command with specific parameters in the sudoers file, only "dumb" string matching is possible.

Strictly speaking, you don't actually even need sudo for granting access to Apache configuration files. Apache does not particularly care what the configuration file permissions are, as long as Apache itself can read them (and if Apache uses ports <1024, it normally starts as root, so reading files is not a problem). So, since you already have a group, you could do this:

 chgrp -R pusers /etc/httpd/conf
 chmod g+rws /etc/httpd/conf
 chmod g+rw /etc/httpd/conf/* 

RHEL7 even uses the "usergroups" system by default, so your users' umask values should already be either 002 or 007. If that's true, then these simple one-time settings are all you need to give your users write access to Apache configuration files. Your users can even create new files in the configuration directory, and they will automagically get the correct group ownership and permissions.

Actually, the most likely way to accidentally mess up the permissions of the configuration files in this scheme would be to add new files to it as root: the root user usually has umask without the group write bit (traditionally 022 or more strict 077), and root power can trump the setgid bit on directories as well.

You might have to learn some new habits, but in this case, unlearning "you must be root to configure Apache" might actually be a good thing. (And if you think sudo provides more audit trail, then really consider placing the configuration files under Git or some other version control system.)