sudo Runas_Alias not working

[javedk]

I have installed ixsudo A.06.00-1.6.8p12 from HP site on HPUX 11.11 server. The Runas_Alias is not working rest are working fine. Following are the entries from my sudoers file.

User_Alias USER=ituser1, ituser2
Cmnd_Alias CMD=/usr/bin/ls
Runas_Alias APPS=appusr

USER ALL=(APPS) CMD

while I try to do "sudo ls" after login as ituser1 I get the following eror message.
Sorry, user ituser1 is not allowed to execute '/usr/bin/ls' as root on hostA

Butif I replace appusr with root in Runas_Alias then "sudo ls" works. It does not work if it is any username other than root.

[Raj D.]

Javedk,
Check if user appusr has been setup correctly in the sudoers file, and permission to /usr/bin/files ...are given.

cheers,
Raj

[Matti_Kurkela]

You're saying here that ituser1 and ituser2 should be allowed to run /usr/bin/ls as appusr, not as root.

If you try "sudo ls" as ituser1, you don't specify which user you want to run the command as... so sudo assumes you're trying to run it as root.

The solution is to "say what you mean":
sudo -u appusr ls

When building sudo functionality for normal users, I usually provide them with a small wrapper script or an alias to hide the "complex" sudo command.

[javedk]

Hi Matti,

Thank you very much for the clarification. I was assuming that it would automaticlly run the command as appusr.

Could you please provide me a sample wrapper script.

[Matti_Kurkela · Accepted solution]

It could be as simple as this:

#!/bin/sh
exec sudo -u appusr "$@"

Name it something suitable (maybe "appusr"?), put it in /usr/local/bin or some other location that is in the users' PATH and give it execute permissions.

The script can now be used like this:

appusr ls -lt /some/directory/somewhere

with an unlimited number of arguments. It works like a simple "prefix" in front of the desired command.

[javedk]

Hi Matti, Thanks a lot for the script.

I had another requirment to provide access to our operation team to certain application folders owned by apps user. kind of access required is "mv,cp,cd,rm,...
Is sudo the best option or should I use ACL.

[Matti_Kurkela]

Allowing a basic file manipulation access *and only that* is a bit laborious with sudo, although certainly do-able.

Since "cd" is a shell built-in command, you cannot use sudo for that. Possible workarounds would be to instruct the users to use full pathnames of the files they intend to manipulate. However, most users don't like to type long path names at every command (autocompletion may not work, as the shell that does the completion is run as the user's normal identity, and may not have the permissions to read the application directories).

The easiest (but not the most audit-proof) solution would be to allow the users to run a shell as appusr (sudo -u appusr /usr/bin/sh, or sudo -u appusr -s). If a secure logging for commands is a requirement, this may not be a valid solution.

If this is a new system, you should consider using the group permissions for files and directories.
For example:
- appusr belongs to group appgrp
- users ituser1 and ituser2 have "appgrp" as a secondary group (usermod -G); the primary group can be anything you like

- the application *directories* have owner appuser, group appgrp and chmod 2770 (setgid appgrp).

- the application *files* have group appgrp and chmod 0660 (group writable, no setuid/setgid)

Now ituser1 and ituser2 can manipulate the application files *using their own identity* and any new files created/moved in application directories get the group "appgrp". If the user sets "umask 007" before manipulating application files, everything works: the application has full access to the directories and files because it is member of the appgrp group and the files are group writable.

Caveat: if the user forgets to enter "umask 007" before manipulating application files, he/she may cause the manipulated files to become writeable only for him/her. If the files are readable by other members of the appgrp group, this is user-fixable: any member of the group can copy the file and remove the original (to eliminate the file with wrong permissions). If the file is readable only by the user that made the mistake, only that user (or someone with root powers) can undo the mistake.
This can cause some extra workload for admins, until the users learn the system.

[javedk]

Thanks a lot. Great response...