no timestamp timeout in latest sudo except for current instance

Bug #692391 reported by Doug McMahon on 2010-12-20
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
sudo (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: sudo

The only apparent 'timeout' is in current open terminal -
ex.
open a terminal - sudo <whatever>, asks for password
Then in same terminal sudo <whatever>, won't ask for password
close terminal and reopen - sudo <whatever>, asks for password

adding a env_reset,timestamp_timeout=X in /etc/sudoers or a file in /etc/sudoers.d has no effect

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: sudo 1.7.4p4-5ubuntu2
ProcVersionSignature: Ubuntu 2.6.37-10.24-generic 2.6.37-rc6
Uname: Linux 2.6.37-10-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Sun Dec 19 20:02:15 2010
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20101215.1)
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 LC_MESSAGES=en_US.utf8
 SHELL=/bin/bash
SourcePackage: sudo
VisudoCheck: /etc/sudoers: parsed OK

Doug McMahon (mc3man) wrote :
summary: - no timestamp timeout in current sudo except for current instance
+ no timestamp timeout in latest sudo except for current instance
Quackers (quackers) wrote :

The silence is deafening in here :-)

Doug McMahon (mc3man) on 2011-02-14
tags: added: regression
removed: running-unity
Doug McMahon (mc3man) wrote :

Have resolved this here by adding a line to sudoers (actually use a file in /ect/sudoers.d/ instead
Defaults !tty_tickets

The issue seems to be the configure option of --with-tty-tickets that was carried forward from sudo 1.7.2 but has a slightly different effect here in 1.7.4 - once the instance is closed the timeout ends
Because of no response don't know if this new behavior was the new intention or just one of those things, no big deal, easily 'fixed' for those that wish the old behavior back (in lieu of some other approach

Ex. here for those that wish to change in sudoers.d or if desiring to re-build sudo then just change the option in /debian/rules to --without-tty-tickets
http://ubuntuforums.org/showthread.php?p=10500211#post10500211

Quackers (quackers) wrote :

Thank you Doug. That's fixed it :-)

Doug McMahon (mc3man) wrote :

After using the both the current natty sudo (1.7.4p) with !tty_tickets and the previous 1.7.2 have decided the best choice here, (for me), is to use 1.7.2p7 (w/ recent security update patch

It uses tty_tickets but gives the expected behavior w/ the admin. auth. timeout and can be adjusted if wished, up or down, with an appropriate sudoers or /etc/sudoers.d/ edit

Also no mouse spin on synaptic or with gksudo nautilus -(in the current natty sudo the mouse spins on for 4 -12 secs

Can't see any reason to atm to build the source on natty so am using the latest package from maverick security updates. (1.7.2p7-1ubuntu2.1

SirG (sirg-nj) wrote :

This appears to be a side effect of trying to enforce tty_tickets properly: back in lucid for commands invoked from the menus the sudo timestamp was written under the name 'unknown'; now it does not get written at all - hence the timeout is not honored.

With tty_tickets turned off, you can be prompted for password once and then any login under that id is not prompted for @timeout@ period, including ones that may be under different controlling terminal, such as a remote ssh login. But this seems to be a better workaround, than having to type in a password every 5 minutes for running synaptic.

With lucid behavior, you could actually get prompted once, and then reboot the machine and not get prompted again, if the terminal name happened to match.

What we really want is for timeout to be shared in a user session - a desktop session, a screen/byobu session, etc. Of course there are nested sessions: screen running in a xterm... And related ones, such as ones on the local ttys :)

Steve Langasek (vorlon) wrote :

From what I can tell, you're describing the intended behavior of sudo wrt per-tty tickets. Closing as invalid.

Changed in sudo (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers