1

I'm trying to execute a script as a different user (say, marvin):

$ sudo -u marvin scriptname

On one machine (Ubuntu 14.04), the command works and the script executes successfully.

On another machine (Kubuntu 16.04), running the same command throws the error

marvin is not in the sudoers file.  This incident will be reported.

marvin is not in the sudoers list on either machine. This shouldn't matter, since the script doesn't require sudo rights to execute. I'm using sudo to act as marvin, but I have sudo rights on both machines. marvin himself is not attempting to perform a sudo action.

Why does this happen? There must be a difference between the two machines, but I can't find it. On both systems, the file ownerships and permissions are identical.

Edit: The /etc/sudoers files on the two machines are virtually identical; the relevant portion is

root    ALL=(ALL:ALL) ALL
%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

Neither mention any regular user, but I (borea) am a member of the sudo group on each. Both have the import line from /etc/sudoers.d/ commented out, and that directory is empty except for the README on both machines, anyway.

1 Answer 1

2

Who a user can 'runas' with sudo is defined in the /etc/sudoers config file. This utility is extremely configurable so I might over simplify a bit. The sudoers manpage covers it exhaustively.

When called, sudo checks the rules for the calling user. In your example that means the rules for user borea are evaluated first, not those, if there any, for user marvin.

The error message from the call definitely doesn't help clarify that point.

A typical 'full sudo privilege' entry in sudoers looks like this:

borea ALL = (ALL) ALL

This is that same statement with context on what each item means:

Who:                     borea 
On hosts:                ALL
Can run as users:        (ALL)
The commands:            ALL

The key entry in context of your question is the third. If that isn't set to ALL it if it is set to a user list that doesn't include marvin, the call will fail.

Here is a more involved example from the man page:

alan    ALL = (root, bin : operator, system) ALL

This setting translates to:

user alan may run any command as either user root or bin, optionally setting the group to operator or system.

So the difference between the behavior on the two systems is not tied to the marvin account but instead to your account. My best guess on the cause is the 'run as' setting, but there are other settings that could prevent it in the same config file, both globally and in other subtle ways (eg group membership).

Other things to look at:

Based on your feedback, the issue isn't with the sudoers file as directly configured for user borea. Here is a laundry list of data points to collect and things to try. Update your question with the results (specifically any differences seen between the two machines).

1. This command will summarize your 'sudo' related privileges and limitations, check if there is a difference reported between the two machines:

 sudo -l -U borea

2. Repeat the same for user marvin. Its definitely not required that marvin be in sudoers for sudo -u to work, but its a good data point. It's possible that marvin inherited some settings by group membership, etc.

 sudo -l -U marvin

3. On both machines, check the status of the marvin account for any differences. finger may not be installed by default; use sudo apt-get install finger first in that case.

 sudo finger -l marvin
 sudo passwd --status marvin
 id marvin

4. Try to open a shell using the marvin account. su uses a different method to escalate privilege:

 sudo su marvin

5. Assuming the root account is enabled for shell access (I think by default Ubuntu still disables that), try this:

 sudo -s
 sudo -u marvin scriptname

6. Confirm the permissions on /etc/sudoers:

 ls -alt /etc/sudoers

The result should start with -r--r----- 1 root root ... If it doesn't, fix it with:

 sudo chmod 440 /etc/sudoers
 sudo chown root:root /etc/sudoers

7. Try copying the sudoers file from the machine were things are working correctly to the machine where they are not. Be very careful doing this - backup the originals to a safe spot. It would be easy to lose track of which file is which...

8. Last thing - check to see if you have a file /etc/sudo.conf on one or both machines. Create a copy of both files if so, and move them to a single machine. run

 diff sudo.conf.machine1 sudo.conf.machine2

to look for configuration differences. Do the same with the /etc/sudoers file (using diff) to find all deltas.

6
  • Excellent idea, thanks! I double-checked, though, and I (as the main user) have the exact same /etc/sudoers status on both machines. I've updated my question with more info. Sep 9, 2016 at 13:41
  • id turned up something interesting. On the Ubuntu 14.04 machine, marvin has uid=999, indicating that his account was created as a system user. On the Kubuntu 16.04 machine, he has uid=1001, a normal user account. Would this account for the difference? Sep 9, 2016 at 17:52
  • I'm not aware of why that would make a difference - as I best I can tell it shouldn't. Any other findings - moving the sudoers file, group memberships etc?
    – Argonauts
    Sep 9, 2016 at 20:21
  • passwd --status showed marvin had NP status on one and L on the other. I changed L to NP so both would match, but that didn't make a difference. I didn't switch sudoers files (#7), but I did diff them and they're the exact same file except that the Kubuntu system has /snap/bin added to the default secure_path. Other than that, no difference between the two machines. Sep 9, 2016 at 21:01
  • Try adding a throwaway account on the 16.04 machine using all defaults: 'sudo useradd temptestuser'. See if you can then 'sudo -u temptestuser scriptname' with that account. That will at least tell you if it is a system config issue or a marvin config issue.
    – Argonauts
    Sep 9, 2016 at 21:06

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.