# why now "sudo: must be setuid root"

## genterminl

I don't think it's been that long since I last used sudo, but today I get the "must be setuid root" error, and sure enough "ls -l /usr/bin/sudo" gives me "---x--x--x 2 root root 147632 Mar  3 13:12 /usr/bin/sudo"  Reinstalling doesn't change this, and "eix app-admin/sudo" gives me " Installed versions:  1.7.2_p4(13:12:29 03/03/10)(pam -ldap -offensive -selinux -skey)"

I know I can do "chmod +s /usr/bin/sudo" but I'm curious whether this is indicative of some other problem.

Am I missing something obvious?

Jack

----------

## ursusca

Hello,

Try this way:

```
chown root:root /usr/bin/sudo

chmod 4755 /usr/bin/sudo

```

and reboot the machine.

----------

## ppurka

 *genterminl wrote:*   

> I don't think it's been that long since I last used sudo, but today I get the "must be setuid root" error, and sure enough "ls -l /usr/bin/sudo" gives me "---x--x--x 2 root root 147632 Mar  3 13:12 /usr/bin/sudo"  Reinstalling doesn't change this, and "eix app-admin/sudo" gives me " Installed versions:  1.7.2_p4(13:12:29 03/03/10)(pam -ldap -offensive -selinux -skey)"
> 
> I know I can do "chmod +s /usr/bin/sudo" but I'm curious whether this is indicative of some other problem.
> 
> Am I missing something obvious?
> ...

 On my system sudo is actually suid root. 

```
---s--x--x 2 root root 162K Mar  3 13:40 /usr/bin/sudo
```

This is for both versions 1.7.2_p1 and 1.7.2_p4 (on two different systems). 

@ ursusca genterminl already knows about how to change it to suid root: only worry is whether this is a security issue or not. According to my installation on two different machines it probably isn't.

----------

## papahuhn

Well, if not suid root, how should sudo give root privileges?

----------

## patrikas

Make sure executable got overwritten when you reinstalled it. Are you using collision-protect or protect-owner features ?

----------

## genterminl

patrikas:  the timestamp on sudo is the time I did the emerge today, so I'm pretty sure it did  get the new  copy.

ppurka:  I'm not questioning whether making sudo setuid root is a security issue; I know that's how it is supposed to be.  I'm wondering why mine is NOT setuid root, and whether that is indicating some other security issue.

It looks like this new version got installed Mar 1, so I'm assuming that's when the change happened, but if there was a problem with the ebuild, I would expect other people to have the problem also.  I can easily fix my immediate problem - I'd just love to know why/how it happened.

----------

## Mad Merlin

 *ursusca wrote:*   

> Hello,
> 
> Try this way:
> 
> ```
> ...

 

This method absolutely does not require a reboot.

----------

## Gentree

That's odd , my windows machine says it needs to reboot every time I change anything. Isn't Linux the same ?

 :Razz: 

----------

## Genone

Do you eventually use the suidctl and/or sfperms FEATURES in make.conf?

----------

## genterminl

Great question - but no, I don't use either of those.  I didn't even know about them until your post.

----------

## M

It happens to me, often, when I mount over nfs old laptop on desktop machine and update sudo or xorg-server, always have to manually setuid. And I have rpc.idmapd started. Maybe you use something similar, just a guess.

----------

## genterminl

The only thing close is that PORTAGE_TMPDIR points to a directory mounted over NFS.   /usr is within / which is a local mount.

----------

## genterminl

I just upgraded sudo (now 1.8.2-r1) as part of a recent world update, and again, /usr/bin/sudo got installed WITHOUT suid set.  Lot's of googling, and no answers, except one hint buried in this topic.

If I emerge sudo with PORTAGE_TMPDIR set to a local disk, /usr/bin/sudo gets installed setuid.

If I emerge sudo with PORTAGE_TMPDIR set to an nfs4 mount, /usr/bin/sudo gets installed without setuid.

This is yet another problem with PORTAGE_TMPDIR on an nfs4 mount, but at least I know why the setuid isn't happening.

This was my original post on the issue.  I'll probably start a new thread summarizing my current understanding, but the bottom line is that setting PORTAGE_TMPDIR to someplace mounted over nfs4 is going to cause various problems, not all of them consistent.

----------

## mcclung

What are the export and mount options on your nfs filesystem?  What kind of NFS server is it?

----------

## genterminl

First, if I remember correctly, using nfs3 does not cause any of these problems, but at this point, I'm trying to find the cause, not just make it work.

The nfs server (ffortso3) is Ubuntu 11.10.  The relevant lines from /etc/export are *Quote:*   

> /exports  ffortso?.home(fsid=0,rw,sync,root_squash,no_subtree_check)
> 
> /exports/portagetmpdir  ffortso?.home(fsid=1,rw,async,no_root_squash,no_subtree_check)

  and the relevant line from /etc/fstab is  *Quote:*   

> /home/portage/tmpdir    /exports/portagetmpdir  none    bind    0 0

 

The client (ffortso4) is Gentoo, and /etc/fstab includes  *Quote:*   

> ffortso3:/portagetmpdir /home/portage/tmpdir  nfs4  nocto  0 0

  and /proc/mounts shows (note I have added spaces after each comma to improve wrapping, but it is really one line) *Quote:*   

> ffortso3:/portagetmpdir/ /home/portage/tmpdir nfs4 rw, relatime, vers=4, rsize=131072, wsize=131072, namlen=255, hard, nocto, proto=tcp, port=0, timeo=600, retrans=2, sec=sys, clientaddr=192.168.1.14, minorversion=0, local_lock=none, addr=192.168.1.13 0 0

 

The "nocto" is just another of my attempts to see if I can find a parameter to avoid all the problems, but I'm still getting th errors.  Adding either "ac" or "lookupcache-none" made both machines unbearably slow, and at this point, I'm not even sure if they actually fixed the problems.  "acregmax=0" also didn't help.

Any other suggestions?

----------

## mcclung

I was expecting something else.  In hindsight, I guess what I was looking for would have been pretty obvious.

----------

## genterminl

For completeness, I suppose I should also specify that I do have idmapd running, with the same domain specified on both machines.

----------

## myk002

after struggling with this for a few days, I accuse 'strip' as the culprit.

# emerge sudo

# ls -l /usr/bin/sudo

---x--x--x 2 root root 71144 Mar  6 10:32 /usr/bin/sudo

# FEATURES=nostrip emerge sudo

# ls -l /usr/bin/sudo

---s--x--x 2 root root 84221 Mar  6 10:34 /usr/bin/sudo

# strip /usr/bin/sudo

---x--x--x 2 root root 71256 Mar  6 10:32 /usr/bin/sudo

I have a diskless system, with everything (including root) mounted over nfs (version 3).  Interestingly, though, /bin/mount (from util-linux-2.20.1-r1) is correctly setuid, even though it gets stripped.

----------

