3

I have a set of storage directories on Linux machines, all 770/root:root (perms/owner:group), for which I use ACLs to manage users access. (I am unable to use unix groups as the directories are shared across a network, where groups are managed via LDAP for which I'm not an admin).

For each directory, one user has full rwx access via ACLs, and all others have rx access via ACLs.

Currently, I have to manually respond to requests to add/remove users, and I'd like this ability to be passed onto the 'rwx' users for the directories they own (because I'm a lazy sysadmin, naturally).

The best solution I can think of is to create a script/program with root setuid that checks for the 'rwx' ACL status of the calling user on the given directory, and allows them to add/remove 'rx' ACL users, as in:

$ modify_acls.sh [--remove] [--add] <my_directory> <other_user>

Is there an easier way of doing it, or will the solution above not work for any reason?

  • 1
    "… or will the above not work for any reason?" It actually probably won't, as setuid shell scripts tend to be disabled – Fox May 3 '17 at 22:23
  • 1
    Instead of a setuid shell script, consider enabling a specific script with sudo. – dirkt May 4 '17 at 8:57
  • 2
    If at all possible, I'd suggest changing the owner of the whole directory tree to something other than root, some user account dedicated to just that. That would protect the rest of the system from issues if someone happens to find a bug in the script you make. – ilkkachu May 4 '17 at 10:56
  • 1
    Are the LDAP admins totally non-responsive? The best solution here is to put users in proper groups instead of trying to kludge some workaround that has the potential to have serious security issues. – Andrew Henle May 4 '17 at 10:59
  • 2
    @einonm, that's the point where you go to your boss and say "I can either do these updates manually, which eats into my work hours and slows down the users; or we can create a tool for this, but it leaves a chance that someone can crack the whole file server; or, the LDAP admins could add one account into the directory..." -- I mean, isn't that what LDAP is for, having organization-wide accounts in only one place... – ilkkachu May 4 '17 at 11:27
1

Instead of a setuid shell script, consider enabling a specific script with sudo.

Even though it's used most often this way, sudo isn't restricted to "allow someone to execute any program as root". You can easily configure "user A, B and C are allowed to execute only this particular script as root" in /etc/sudoers. See man sudoers for details.

There isn't really an advantage of using sudo instead of a setuid script, except that on systems where setuid scripts are completely disabled for security reasons, the second alternative just won't work at all. You still could write a custom setuid binary, but inserting a line into sudoers is simpler, quicker and easier to change later on when you want to add or remove users.

  • 3
    sudo does have the advantage that it sanitizes the environment by default, and the feature can be configured if some envvars need to be passed through. That's especially important with shell scripts (as opposed to binary executables), since a script is likely to run other applications that may change behaviour based on envvars. – ilkkachu May 4 '17 at 10:55
1

Using a shell script will probably not work as setuid shell scripts are typically not supported on Linux.

A workaround would be to write a small executable In C to provide the required functionality and setuid root this executable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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