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
** Changed in: sudo (Ubuntu)
Assignee: (unassigned) = Martin Pitt (pitti)
--
sudo -k fails when timestamp is in the future
https://bugs.launchpad.net/bugs/43233
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing
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
Not only that, but it's a very good solution. I'm surprised it hasn't
been implemented yet.
--
sudo -k fails when timestamp is in the future
https://bugs.launchpad.net/bugs/43233
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
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.
--
sudo -k fails when
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
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:
[EMAIL PROTECTED]:~$ date
Mon Oct 8 15:59:47 EDT 2007
[EMAIL PROTECTED]:~$ sudo echo
sudo: timestamp too far in the future: Oct 8 20:54:16
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.
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
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
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
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
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
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.
--
sudo -k fails when timestamp is in the future
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.
--
sudo -k fails when timestamp is
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
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
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
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
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.
--
sudo -k fails when
On Mon, 2007-02-19 at 17:04 +, 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
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
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
--
sudo -k fails when timestamp is in the future
https://launchpad.net/bugs/43233
--
ubuntu-bugs mailing
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
Edit: I have edited the sudoers at some time, but I don't believe I have
changed the default options provided.
--
sudo -k fails when timestamp is in the future
https://launchpad.net/bugs/43233
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
On Thu, 2007-02-15 at 09:27 +, 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
On Tue, 2006-12-12 at 17:00 +, 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
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,
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
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
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
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?
--
sudo -k fails when timestamp is in the future
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
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
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
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
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
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
39 matches
Mail list logo
