Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Every since I upgraded all my linux-vserver Debian guests from Lenny to Squeeze I've the apparent problem that whenever I want to use sudo it asks me for my password. Every time.

I've configured sudo to have a timeout of 30 minutes: Defaults timestamp_timeout=30 . This has been configured when it was still Lenny (note: as suggested by EightBitTony I've also tried without this setting -> no change).

I've a hard time figuring out what the problem here is, since I think my configuration is right.

I thought about it being a problem with the file used to record the timestamp, maybe a permission issue, but was unlucky to find any hard evidence. I've compared the contents of /var/lib/sudo/ between a working and a non-working system but couldn't spot any difference. The version of sudo used in both environments is 1.7.4p4-2.squeeze.3.

My non-working system(s):

find /var/lib/sudo/ -ls
17319289    4 drwx------   4 root     root         4096 Jan  1  1985 /var/lib/sudo/
17319286    4 drwx------   2 root     mark         4096 Jan  1  1985 /var/lib/sudo/mark  
17319312    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/6
17319361    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/9
17319490    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/10
17319326    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/4
17319491    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/2

A working system:

find /var/lib/sudo -ls
2598921    4 drwx------   5 root     root         4096 Jan  1  1985 /var/lib/sudo
1999522    4 drwx------   2 root     mark         4096 Jan  1  1985 /var/lib/sudo/mark    
2000781    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/8
1998998    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/17
1999459    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/26
1998930    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/24
2000771    4 -rw-------   1 root     mark           40 Jun 25 11:39 /var/lib/sudo/mark/4
2000773    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/5
1999223    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/0
1998908    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/14
2000769    4 -rw-------   1 root     mark           40 Jul  9 13:30 /var/lib/sudo/mark/2
2000770    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/3
2000782    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/9
2000778    4 -rw-------   1 root     mark           40 Jul  8 00:11 /var/lib/sudo/mark/7
1998892    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/19
1999264    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/23
2000789    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/12
1999093    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/25
1998880    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/18
1998853    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/20
2000790    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/15
1998878    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/16
1998874    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/13
2000774    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/6
2000786    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/11
1998893    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/22
2000783    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/10
1998949    4 -rw-------   1 root     mark           40 Jan  1  1985 /var/lib/sudo/mark/1

Despite the obvious (some up2date timestamps on the working system) I don't see anything wrong here, so it could be as well be a wrong track.

Here's my current /etc/sudoers:

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification
User_Alias FULLADMIN = user1, user2, user3

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL
FULLADMIN ALL = (ALL) ALL

# Allow members of group sudo to execute any command
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=(ALL) ALL
#
#includedir /etc/sudoers.d
#Defaults always_set_home,timestamp_timeout=30

Update 2012-07-19:

I wrote to the linux-vserver mailing list and was asked to provide an strace output (took me a while until I figured I need to set strace suid root for this):

http://my-serve.rs/tmp/serverfault-406010-strace-notworking.txt

(I couldn't include the output here, serverfault said body is limited to 30000 characters)

I've tried to compare this strace to one of a machine where it is working (I was smart enough to remove the PIDs ...), still they were so many changes that it was impossible for me to spot anything.

While going through the strace output, I also checked the system logfiles and found one obvious different between a working and a non-working environment:

Log entry from working machine:

Jul 19 09:06:31 server sudo: theuser : TTY=pts/2 ; PWD=/tmp ; USER=root ; COMMAND=/bin/ls

Log entry from non-working machines:

Jul 19 09:00:16 server sudo: theuser : TTY=unknown ; PWD=/tmp; USER=root ; COMMAND=/bin/ls

I've learned that there's a file called /etc/securetty which lists all TTYs allowed for root log in. This can be also seen in the strace output. I tried to add unknown but it didn't make any difference.

I was asked what who am i does; there's no output when I run this command. But it's the same no output in a vserver guest with working and non-working sudo.

I enter the vserver (from the host) with: sudo vserver <vserver> exec su - username and from this point on I pretend to have logged in normally and start working, trying to use sudo sometimes, etc.

Update from 2012-10-19:

No solution unfortunately, but I think what Michael said in the comments is the root cause:

I think it means that sudo is not the root cause of the problem; the apparent lack of a terminal is.

I tried to get in contact with the people at vserver but unfortunately so far they couldn't help me. I also realize I'm running an older version (or also a so called "debianized" version) which may have its own problems (sometimes; I was told).

Update from 2013-10-03:

Unfortunately I could never figure out what the problem was. Now that Debian Wheezy has been released for some while I'm already running vservers with it which don't have this problem.

share|improve this question
    
If you take the Defaults timestamp_timeout=30 entry out, does it go back to the default of 5 minutes? i.e. take that line out, and re-test and see if it works, but uses the 5 minute default. –  EightBitTony Jul 9 '12 at 12:32
    
@EightBitTony: no change in behavior :( –  mark Jul 10 '12 at 8:36
    
The contents of the sudo.conf file would be helpful. –  Jenny D Jul 10 '12 at 8:58
    
@JennyD: you're right, added (sudoers, there's no sudo.conf on my system) –  mark Jul 10 '12 at 9:01
    
Of course it's sudoers, sorry about that. Do you have anything in /etc/sudoers.d that would change the timestamp_timeout option? –  Jenny D Jul 10 '12 at 9:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.