"sudo -k" fails when timestamp is in the future

 severity wishlist
 status confirmed

That sudo refuses to do anything when this happens is a safety measure.
A sudo -K as you describe would be a nice feature though.

Agreed. It is acceptable that a plain "sudo" refuses to work in such a case. Commands "sudo -k" and "sudo -K" should still work, as stated.

This is an absolute pain in the arse when Windows adjusts your hardware clock to local time over the Summer.

"sudo -k" and "sudo -K" really SHOULD work, it's in sudo's man page and in the usage overview.

The sudo timestamp problem happened to me on a freshly installed Edgy (xubuntu), without my ever actively resetting the clock at any time. Like kko, I had a lockup (bug 41340), pulled the power plug, then rebooted, which may be what somehow caused the timestamp difference.

The system clock (as shown by /bin/date) was within a minute or two of the correct time. I don't know what file's timestamp sudo was checking, so I can't say whether it was in the future or past.

Curiously, the workaround (found by googling: lots of people are hitting this on Ubuntu) was to set the date to the future deliberately (using the gui time/date tool, which apparently doesn't need sudo) then run sudo -k -- even though it seems like that's exactly what this bug report says doesn't work.

Apart from the fact that the warning message might be a bit scary, I don't see a problem with it. After all, it is true, and if your clock jumps, then there's definitively a problem.

So what exactly do you want to change here?

The sudo man page says that -k and -K should reset the timestamp. If that's not really what they do, could the man page be updated to describe their actual functions? (What do they really do?)

Since this is something that seems to happen pretty commonly during the edgy install process (comments in the two bugs here, plus lots of google hits), it would be really useful to have a way of doing what the man page says -k/-K do: reset the timestamp now, so that the next call to sudo will prompt for a password. Currently, once it gets into this state there's no way of getting out, unless you have some other way of resettting the system clock; sudo just keeps repeating the error message and -k and -K don't fix it.

Martin Pitt: Obviously, if there is a problem (with something that causes the clock to jump), the user probably needs to be able to use root capabilities (e.g. 'sudo') to rectify the problem. For this, resetting the timestamp is what is often needed, as indicated by these reports.

As I stated in a previous comment, it is a good thing that normal 'sudo' commands without the '-k' or '-K' switches do fail if the timestamp is too far in the future. This serves the purpose of alerting the user to the fact that something is amiss. However, when the user then starts to rectify the problem, it really doesn't help if 'sudo -k' or 'sudo -K' don't work as stated in 'man sudo'.

In sum, if the user has to find a workaround (as indicated here) to be able to tackle the problem, it seems to me that the user has to jump through unnecessary hoops.

(Akkana Peck: Adapting the man pages to reflect current limitations would be a bad option, in my opinion - I'm sure you agree, though. The commands 'sudo -k' and 'sudo -K' do normally work, cleaning the timestamp as stated and thus forcing the password request for next usage of 'sudo', just as long as this bug doesn't prevent this from happening.)

Martin, you said:

"Apart from the fact that the warning message might be a bit scary, I don't see a problem with it. After all, it is true, and if your clock jumps, then there's definitively a problem."

The problem is, if I adjust my computer's clock, and it can happen for a variety of reasons including a bug in edgy that I suppose misconfigures the NTP client - let's not talk about that now - I can no longer become root to administer my system. If I move the clock backward, though, I can, hence security is not increased, but usability is decreased - this is how I see it. Is there a simple way to remove the "mark" using the root password?

Martin, you said:

"Apart from the fact that the warning message might be a bit scary, I don't see a problem with it. After all, it is true, and if your clock jumps, then there's definitively a problem."

The problem is, if I adjust my computer's clock, and it can happen for a variety of reasons including a bug in edgy that I suppose misconfigures the NTP client - let's not talk about that now - I can no longer become root to administer my system. If I move the clock backward, though, I can, hence security is not increased, but usability is decreased - this is how I see it. Is there a simple way to remove the "mark" using the user's password? (if this gets posted twice, it is because I am a little dumb :))

Just for the sake of helping a guy out, even though answering what could be called support requests isn't strictly bug tracker stuff... well, at least it serves to illustrate the issues faced.

Vincenzo: Workarounds exist, the most troublesome of which would probably be using a rescue-CD to get access to the files needed.

Now, the timestamps get stored as root-only-accessible files in /var/run/sudo/yourusername/, and removing them manually will invalidate the timestamps, as I briefly mentioned in my initial report. You could try using sudo from another tty (Ctrl-Alt-F1 through F6), or from another shell in X to remove these files. This should allow you to use sudo normally, at least until your clock breaks again. ;-)

(Using graphical approaches, e.g. a root-mode file manager, to get root access to the files will probably work, too - I haven't checked how e.g. kdesu or gksudo use/store timestamps.)

Thank you, however that wasn't a support request, but a comment on the bug: I was able to solve that myself for my own system, but I am a true geek. My question is if there exists a workaround which is discoverable by an average user. I am concerned about ubuntu usability.

When you install edgy, you can set up an NTP client, but you can do so without setting a server, and there's no default. You don't notice this since the "select servers" dialog is hidden behind a button, and it's a checklist that is initially empty. This can go unnoticed and you soon find your system, don't know exactly why, a month in the future. This is a current problem in edgy, it seems, from a google search. You discover this, go to clock settings and either adjust time manually or set up the NTP server. You can no longer update your system - and, if you don't know how to enter a text-mode console, things won't be fixed up even when rebooting, this is what happened to me, and this should not happen at all. Notice that this bug can happen to every ubuntu newbie, that will no longer be able to use synaptic for example, and that there are two issues involved here, one of which is this bug 43233.

We should have slightly relaxed security checks on a desktop system, ensuring that a member of the admin group can always recover his own system in an easy way, expecially when the damage can be done in an easy way (simply adjusting the clock).

Rebooting the system, for example, should in my opinion reset all of a system state, timestamps and printer queues included. You can't imagine how many printer-queue related problems my 70 years old mother encountered using linux, until she asked me kindly to give her what technicians in her small town only knew about: the OS with the majority market share, that you know about at least for the #1 bug in ubuntu.

So my solution for the bug is: make sudo -k work as expected, and make rebooting the system delete the timestamp. If you don't agree I won't get angry :) it's just that I would like to see a linux distribution that my mother can really use, and this is still not the case with my favourite one.

Sorry for long comments I sometimes leave on launchpad, that might be considered inappropriate, but I feel that what is considered a bug or a feature can be changed only by explaining reasons and use cases, so I attach those reasons to the bug itself. In fact, that sudo -k doesn't work can be considered a feature on a server, I understand this.

Ah, I see what you mean now. Regardless of how hard I try, I just get the error messages, type my password, and then sudo works just fine. Thus I assumed you only talk about getting that message.

If sudo actually refuses to work, then that's indeed a huge problem. Can you please try to write down a recipe which reproduces the problem?

I can't now, and I don't know why: it just gives a warning, and I can use sudo -k; anyway I can assure that it happened :) On the other hand, kko's original report seems to suggest the same behavior that I observed originally and not just the warning that I am getting now by following his steps.

I am using Kubuntu Dapper ("sudo -V": Sudo version 1.6.8p12), and my original recipe still "works" for me.

I might add that "sudo -v" (small v, not capital V) doesn't work either, even though it, like the -k and -K switches, could possibly be used to rectify the situation. ("man sudo": "By giving sudo the -v flag a user can update the time stamp without running a command.")

So, to recapitulate:
- You can use sudo from a different shell or from a different tty, even when you have a "bad" timestamp file for another shell or tty. Utilising this fact you can
- 1) set the time to the future (3 hours is more than enough),
- 2) from another shell, issue "sudo rm /var/run/sudo/yourusername/*" to remove all the timestamps - this is important to reliably simulate the effect,
- 3) following my original recipe, log in on the first virtual console (tty1),
- 4) and change the time to current with "sudo date -s hh:mm:ss".

- At this point, when I try "sudo -k", "sudo -K", "sudo -v", "sudo ls -l", or indeed anything "sudo", _and_ do it from the same virtual console (tty1), all I get is "sudo: timestamp too far in the future:" followed by the date and time of the timestamp file (/var/run/sudo/myusername/tty1, in this case).
- I repeat that I _do not_ get "sudo" asking for my password for any of the "sudo" commands named above, I _only_ receive the warning.

To illustrate the point - if I now login on the second virtual console (tty2), I can use sudo there (and it will ask for my password, as required), and will obtain the following results:
$ sudo ls -l /var/run/sudo/myusername/
Password:
total 0
-rw------- 1 root root 0 2006-12-13 22:01 tty1
-rw------- 1 root root 0 2006-12-13 19:09 tty2

In between those timestamps I have switched the time from 22-something to 19-something.

(To be completely truthful, I had a couple other timestamp files there too, from Konsole sessions I tested, but for the sake of clarity I removed those from the extract.)

Sorry, have to correct myself... you _can't_ actually use "sudo rm /var/run/sudo/yourusername/*", because the shell will fail to interpret the wildcard and will tell you that the file or directory doesn't exist.

So, you have to remove the timestamp files individually, giving their proper names, or - more efficiently - do "sudo su" followed by "rm /var/run/sudo/yourusername/*" and "exit".

On Tue, 2006-12-12 at 17:00 +0000, Martin Pitt wrote:
> Apart from the fact that the warning message might be a bit scary, I
> don't see a problem with it. After all, it is true, and if your clock
> jumps, then there's definitively a problem.
>
> So what exactly do you want to change here?
>

Sorry for not replying earlier - a filter had misfiled your email, and
I'll have to fix that. Also, I was out of town for a while.

The issue was not a warning message, but rather that I could not clear
the time stamp so that sudo would not allow me to preform an operation
after prompting for a password.

There was definitely a problem with my system - I had accidentally set
the date incorrectly when I installed ubuntu, used sudo, and then reset
the date when I noticed the error
.
I had one terminal window where sudo would work, so I used that to set a
root password, which allowed me to work around the problem, but avoiding
the need for a root password is the main reason for using sudo.

If you get the dates really messed up (typically as the result of a user
error), sudo -k should simply allow you to remove the time stamp. I
think what it did was to check the timestamp first because I couldn't
seem to solve the problem.

I still need a *detailled* recipe how to reproduce this -- I tried various combinations for half an hour without success.

Hello. I'm still on Kubuntu Dapper, I don't know what you are using. (My sudo package is version "1.6.8p12-1ubuntu6", and "sudo -v" gives, accordingly, "Sudo version 1.6.8p12".)

Here's what I just used for reproducing this:

0) Boot up.
1) Do "ctrl-alt-f1" and login on tty1 as yourself.
2) "sudo date -s xx:yy:zz" where xx:yy:zz is at least two hours in the future (I used "14:00:00")
3) "sudo date -s aa:bb:cc" where aa:bb:cc is two hours and ten minutes less than xx:yy:zz (I used "11:50:00")
4) "sudo -k"
5) "sudo -K"
6) "sudo -v"
7) "sudo ls"

Parts 4 through 7 give the same error, timestamp too far in the future.

Re-browsing the discussion above, I feel it necessary to add that _none_ of the commands 4 through 7 give me the opportunity to input my password. If I read you correctly, it does for you, Martin. For this reason I am beginning to suspect differences in how sudo is configured for causing this. I will attach my "/etc/sudoers", though I believe it is the standard one shipped with Dapper.

(Now, here's a hint that something _may_ be amiss and possibly even depend on the individual system. If I was observing closely enough, on the very first time I tried this today, "sudo -k" wouldn't work, but "sudo -K" immediately after that did. I used much the same procedure as above, but not the same times by the second etc. I'm sorry that I can't confirm this to 100%, since I don't have a videographic memory... If this really was happening, though, it would seem possible that the program unintentionally used some random bit in the memory for identifying what to do.)

Edit: I have edited the sudoers at some time, but I don't believe I have changed the default options provided.

On Thu, 2007-02-15 at 09:27 +0000, Martin Pitt wrote:
> I still need a *detailled* recipe how to reproduce this -- I tried
> various combinations for half an hour without success.
>
> ** Changed in: sudo (Ubuntu)
> Status: Confirmed => Needs Info
>

I think kko answered it. When I reported the bug, I had accidentally
set the date while installing ubuntu Dapper 3 days past what it
should have been. The version of sudo I was using was the one that
came with ubuntu 6.06 in October 2006. sudo accepts minor variations
in the date, but not large ones.

In my case, sudo did not have to be run when I set the date to the
wrong value as it was during an installation. It might help to
set up a root password and bypass sudo to set the date into the
future, and then run sudo to set the date back. In addition, for
some reason one of my terminal windows could use sudo successfully,
but the others could not, including newly opened terminal windows.
I would guess (but cannot say definitively) that this was either
the window I used to set the date, or one where I has run sudo just
prior to setting the date using the "time and date" menu item from
the GUI.

My /etc/sudoers contains the following (as far as I know, it is what
comes with my ubuntu distribution):

------------------------------------
~$ sudo cat /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.
# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults

Defaults !lecture,tty_tickets,!fqdn

# User privilege specification
root ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

I just noticed that the same problem is discussed in bug #24217. That report was in the "CLOSED" state at the time I filed this, but has been re-opened in december. As it was re-opened by someone with a @canonical.com -email address, I am hesitant to myself close it as a duplicate of this one, even though I understand that prioritizing earlier reports is by no means the sole criterion of deciding which one to mark as a duplicate.

Having spent time on tracking this issue, I feel confident enough to say that this report more usefully pinpoints the issue at hand. Namely, that sudo has built-in features to solve the situation (these being 'sudo -k', 'sudo -K' and, if so desired, 'sudo -v'), but something prevents the features from working as intended and as defined in the application's man page.

Martin Pitt: If you agree with my assessment above, can you please mark the above-mentioned report as a duplicate of this one.

Indeed, using kko's recipe I could *sometimes* reproduce it on Dapper, and not at all on Feisty. But since Feisty does not have any changes wrt. ticket handling compared to dapper and because I cannot reliably reproduce it in Dapper either I guess it still affects Feisty in some way.

However, I could log into a different console/pty without any problem in every case, so it never locked me out completely. Did that happen to anyone?

Martin Pitt wrote:
"However, I could log into a different console/pty without any problem in every case, so it never locked me out completely. Did that happen to anyone?"

In short, no, not to me. I believe that having the option "tty_tickets" in '/etc/sudoers' should prevent this from being a real possibility.

(I did point out at some point that _if_ your X failed to start _and_ you only had one getty configured, you'd be in slightly more trouble. Of course, if you've modified your install this much, you know how to e.g. use a rescue disc.)

Also, if you remove the option "tty_tickets" from '/etc/sudoers', by logic this bug should completely lock you from using 'sudo', if 'sudo -k' and 'sudo -K' still refuse to work. We can assume this would be the case, but I don't feel like taking the trouble to confirm that.

On Mon, 2007-02-19 at 17:04 +0000, kko wrote:
> Martin Pitt wrote:
> "However, I could log into a different console/pty without any problem in every case, so it never locked me out completely. Did that happen to anyone?"
>
> In short, no, not to me. I believe that having the option "tty_tickets"
> in '/etc/sudoers' should prevent this from being a real possibility.
>
> (I did point out at some point that _if_ your X failed to start _and_
> you only had one getty configured, you'd be in slightly more trouble. Of
> course, if you've modified your install this much, you know how to e.g.
> use a rescue disc.)

It is possible to be in a situation where you can't easily use a rescue
disk. To give an example, I once worked on a project at Sun
Microsystems where we had to continue working over the Christmas
break. I had non-refundable airline tickets, so I during the
break, I was about 3000 miles away from our lab, logged in via a
VPN and using VNC. We had a mix of systems, including a Linux
one attached to a terminal server via a serial port. We'd use the
terminal server to boot the system and get some messages when Linux
crashed (we were developing a loadable kernel module). It was really
important to be able to do as much as possible without physical access
to the computer. Losing root access would have been a real
annoyance - you might have to call someone and ask that person to
drive into work to fix it.

Regards,

Bill

Bill Zaumen: You're right, there are many possible scenarios.

However, if I understand correctly how the kernel assigns new pts numbers, I think it should be possible to circumvent the problem you described. That is, if you keep your old connection open, and start a new one, you should get a new pts number for the new connection, with fresh sudo capabilities. (I imagine there may be situations where the amount of connections has been limited, but usually I think this should work.)

Of course, we're again assuming that we _are_ using the default "tty_tickets" option.

I just had this happening on an Ubuntu Edgy server running in a virtual machine, what a pain to get fixed. :) I finally found out that I had to open my virtual machine program, login to a seperate tty and sudo from there, as no ssh connection allowed me to do this.

It was the same as above, and neither sudo -v, sudo -K or sudo -k allowed me to enter a password.

This often happens just after reinstall of a system, too.

Got that one as well on a ps3 today... date jumped back 1h (due to some incorrect daylight saving setting I suspect) and sudo stopped working .. for 1h.

sudo -k or -K should really be fixed to at least fallback to asking the password if the timestamp is crap.

Why emit a warning anyway? Why not ask the password instead? Or at least why not simply ask for the password after the warning? I struggled with this for a while in Feisty and I overlooked the options "-k", "-K" in the manual.

I was talking a person in another country through the install of Ubuntu Server via IM today, with the intention of taking over via SSH as soon as possible (he doesn't know anything about command line Linux). Everything worked fine until - boom - when trying to install SSH, this error just happened to us, no idea why. There's no dual boot, and for that matter, the machine never rebooted since the one after install. Possibly, since we didn't have internet from the start, it adjusted the time from NTP when I got him to restart networking to get a DHCP IP.

In either case, this was a very bad situation since almost all Google said was stuff like "sudo -K" and adjust date/time, su to root that doesn't exist - well, just a lot of stuff that didn't work. The switch terminal trick saved the day this time, but that was really hard to find, and I'm not sure it'll always work?

This isn't the most typical situation, granted, but there needs to be an easier - and documented - way to fix this when it happens. It's pretty easy to fiddle around with say internet settings and suddenly have the date changed behind the back via NTP, it's not always "broken Windows" that is to blame.

At the very least a sudoers user with a valid password should be allowed to reset the timestamp. If this feature is necessary at all...

pitti: I hit this last night after debugging suspend/resume with the sysfs trick to store magic data in the RTC. Upon resuming the laptop clock was obviously full of non-clock data, and was interpreted as somewhen around 2016. Any sudo operation in an existing pty refused to do anything because the timestamps were too far in the future.
Opening a new pty allowed me sudo access from there, which I could reset the clock with, using ntpdate.

I just got hit by this one, not knowing I could work-around it just using another tty. I guess this is specially bad in a Ubuntu server, which I had just installed on a new machine, which probably had a very wrong hardware clock setting. After a few tries to -k the token, I just rebooted it. Not ideal. :)

I had this just now, on Xubuntu Feisty, and it took a little time to find a workaround, since sudo -K didn't help at all, and so I couldn't do anything as root. I found an article in the Absolute Beginners' Forum (yes, this is a usability issue) and posted my experiences and workaround at http://ubuntuforums.org/showthread.php?p=3385517#post3385517 - this really does need fixing, as it was only the CMOS clock that was wrong, not the system clock.

Why is sudo dependent on the CMOS clock at all? Normally I'd expect this to be read on boot and written on shutdown, and never used apart from that.

I generally like the idea of sudo'ing, but I've now created a root password just in case.

This has been a problem on my server at work.
It turned out that a hard drive was corrupting the hwclock. I don't know how it was doing this but every time the machine rebooted with the hd connected the date in cmos would reset to 00/1/1983. With the any other drive in its place it works fine.
The issue with sudo -K not working is very annoying because the server only gets reset when I am doing some sort of maintenance where I will need to use sudo.

It seems that the only way I can use sudo -K is to open another tty. If this is by design, then shouldn't the man page be revised?

edit to previous post:
Actually I am not able to use sudo -K at all through ssh
I had to go into /var/run/sudo/username/ as root using sudo su
where i had:
-rw------- 1 root root 0 2008-04-20 12:05 0
-rw------- 1 root root 0 2007-09-24 13:59 1
-rw------- 1 root root 0 2007-09-24 13:58 tty1

then i just touch 0
and that fixed it.
I wonder if sudo -K only works with tty#
(the 0 and 1 are ssh sessions)

I can confirm this on gutsy. I am logging on a headless machine through ssh without physical access, so the only thing I can do is wait... A paste follows:

stavros@storage:~$ date
Mon Oct 8 15:59:47 EDT 2007
stavros@storage:~$ sudo echo
sudo: timestamp too far in the future: Oct 8 20:54:16 2007
stavros@storage:~$ sudo -k
sudo: timestamp too far in the future: Oct 8 20:54:16 2007
stavros@storage:~$ sudo -K
sudo: timestamp too far in the future: Oct 8 20:54:16 2007
stavros@storage:~$ sudo echo
sudo: timestamp too far in the future: Oct 8 20:54:16 2007

This is a usability issue for beginners (it's been logged a few times in the Absolute Beginners) and even experts can have trouble working around it.

Since sudo's use of a timestamp is an optimization to avoid having to re-enter the password a lot, can I suggest the following, also mentioned twice above:

- if the timestamp is too far in future, simply ask for the password rather than emitting this error message

This would completely solve this issue, and in my view would not introduce any security risks. This fix is better than fixing the -k or -K options - much simpler to implement and *much easier* for a beginner or expert to still get logged in.

We should still try to fix sudo -k/K of course, so that automated scripts can run, but I think the primary fix should be to enable an interactive user to get logged in.

It's more than a usability issue. Sometimes there's *no* workaround (e.g. when that happened to me on a PC at work and I was miles away without anyone to fix it locally). I like your solution very much, it would fix this problem without compromising security. I second it.

It's winter time again and somehow Gutsy didn't adjust the time automatically so I've set up ntp and first manually performed an ntpdate-update with the result that sudo didn't work anymore. Automatically rerequesting the password when the timestamp is in the future seems to be the only reasonable solution.

Not only that, but it's a very good solution. I'm surprised it hasn't been implemented yet.

sudo (1.6.9p6-1ubuntu1) hardy; urgency=low

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - debian/prerm: Abort package removal if there is no root password.
      Forwarded to Debian #451241.
    - sudoers: Add some explanatory text why it is a REALLY good idea to use
      visudo. (LP #11620)
      Forwarded upstream: http://www.gratisoft.us/bugzilla/show_bug.cgi?id=269
    - debian/rules: Disable lecture, enable tty_tickets by default.
    - debian/rules: Configure less confusing default password prompt to point
      out that it is sudo asking for the user's password, as opposed to
      another program like ssh, or asking for the root password. (LP #8556)
      Forwarded to Debian #343268.
    - Add debian/sudo_root.8: Explanation of root handling through sudo.
      Install it in debian/rules.
    - sudo.c: If the user successfully authenticated and he is in the 'admin'
      group, then create a stamp ~/.sudo_as_admin_successful. Our default bash
      profile checks for this and displays a short intro about sudo if the
      flag is not present.
  * New upstream version 1.6.9 fixes the following bugs:
    - Does not ask for password any more if stdin is not a terminal.
      (LP: #130636)
    - sudo -k/-K does not fail any more if timestamp is in the future.
      (LP: #43233)
  * Drop our very intrusive patch for selectively cleaning the environment
    based on whether the user can execute all commands or only some. Debian
    and upstream now default to cleaning the environment unconditionally and
    provide option -E and the SETENV tag to override it.
    Instead, do a tinpy patch to parse.yacc which enables SETENV implicitly
    for 'ALL' commands.
    Forwarded upstream: http://www.gratisoft.us/bugzilla/show_bug.cgi?id=268
  * sudo.c: Disable i18n for now (upstream enabled it in 1.6.9), since this
    causes PAM to output localized password prompts, which in turn breaks -p
    and --with-passprompt, which finally breaks gksu. See
    http://www.gratisoft.us/bugzilla/show_bug.cgi?id=270 for details.

sudo (1.6.9p6-1) unstable; urgency=low

  * new upstream version, closes: #442815, #446146, #438699, #435768, #435314
    closes: #434832, #434608, #430382
  * eliminate the now-redundant init.d scripts, closes: #397090
  * fix typo in TROUBLESHOOTING file, closes: #439624

 -- Martin Pitt <email address hidden> Wed, 14 Nov 2007 14:23:47 +0100