I need to set up a particular security arrangement on an Oracle 8 system.

There will be some users which will be added to a unix group.

These users should not be sudoers/in the wheel group, and neither should the group confer admin privileges.

As a result of being in this group, these users should be able to execute but not change certain scripts.

When executed by these users, these scripts will need to able to read and modify certain files, however, the users should not have any access (not even read) to these files by any other means.

How do I set up the unix file permissions/folder structures/group memberships to bring such an arrangement into effect?


2 Answers 2


The users can be trivially added to a new group. Scripts (as distinct from executables) cannot be assigned privileges through setgid/setuid permissions, so the group will need an entry in the sudoers file to confer privileges to its users when they run the selected set of scripts. (The privilege need not - and indeed should not - be root access.)

Starting point. Let's call the group ops, and we'll have users alice and bob. They should be able to execute the scripts in /opt/scripts as user privops, which we'll also need to create. You may prefer to use the same name for the user and group, but I've kept them separate here to make it clear which is which.

First of all create the target user, the membership group and add users to it:

useradd privops
groupadd ops
usermod -a -G ops alice
usermod -a -G ops bob

Now using visudo add a new line to the sudoers file (or better still, create your own file visudo /etc/sudoers.d/ops):

%ops ALL=(privops) NOPASSWD: /opt/scripts/*

At this point, Alice and Bob can use sudo to execute scripts from the /opt/scripts directory as the user privops. Ensure that the directory's scripts are executable only by members of the group ops:

chown root:ops /opt/scripts/*
chmod ug=rx,o= /opt/scripts/*

You should ensure that the restricted access files are owned by privops and can be read/written only by that user account:

chown privops:ops /opt/privdata/*
chmod u=rw,go= /opt/privdata/*

Example usage (first pass):

# As alice
sudo -u privops /opt/scripts/myscript arg1 arg2…

If you want to improve the usability of the scripts, have them call themselves with sudo if they aren't already the target user.

if [ "$(id -nu)" != 'privops' ]
    exec sudo -u privops "$0" "$@"
    exit 1

# original code continues from here…

Alice and Bob can then use the commands like this, or even have them added to their $PATH

/opt/scripts/myscript arg1 arg2…

# Or
export PATH="$PATH:/opt/scripts"
myscript arg1 arg2…

Because you are adding privileges to the scripts in /opt/scripts ensure that they are written particularly carefully, with no opportunities for the caller to break out. Since you seem to be unfamiliar with this type of solution you may want to take professional advice.

  • I want to really emphasize that last paragraph. That is really hard, and it's likely a determined attacker will find away around most simple approaches.
    – mattdm
    Jan 30 at 10:53

Consider doing this a different way. Rather than allowing users to run scripts which have elevated privileges, allow those users to do something more limited, and have a separate process watch for that action and respond.

One way to do this would be to set up an /opt/commands directory, writable by users in the given privileged group (probably the restricted deletion flag, which keeps people from removing files belonging to others.

Then, a separate process running as a dedicated user would look for new files there (using inotify, or simply running every 10 minutes to check, or whatever). If a new file matches a carefully defined list of special names, run the appropriate script to modify the hidden files. The "command" files could even have contents which could be used as input. You must be very careful to "sanitize" this input — and to not use it in any way where it could be executed — but this is an easier problem than trying to make a restricted shell script safe. (Still, easy to mess up!)

This indirect approach means that there is no point when the user actually has permissions to read and write the secret files but is supposed to be limited from actually doing that.

This is a kind of hacky "sysadmin made it work" approach. As a former sysadmin, I find no shame in this. But, rather than the filesystem-based approach here, you might consider using dbus, which is basically made for this kind of situation.

  • This means that the users will have access to the files "by other means" while the privileged operation is being run.
    – symcbean
    Jan 30 at 12:02
  • 1
    Sticky bit would also stop the privileged app from removing flag files it had processed, unless it were to run as root Jan 30 at 14:39
  • 1
    Another solution is a (named) pipe. Tools like ClamAV and SpamAssassin use this approach. It's another way of providing a tightly controlled interface to the process that actually performs the work Jan 30 at 14:40
  • @symcbean How so?
    – mattdm
    Jan 30 at 20:09
  • @ChrisDavies Yeah — any kind of filesystem-based approach is a bit of a kludge.
    – mattdm
    Jan 30 at 20:11

You must log in to answer this question.

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