sudo temp permission not being revoked.

The time is still ticking for the user. I believe the sudo access is in a file with a time stamp (or similar). You can log a bug if you wish.

You can also add the command:

sudo -k

to your logoff script and it will il the sudo session when you logoff

Thank you for your fast reply, i have filed a bug report now.
Thanks for the logoff advice, this will help me out untill a fix is released.

Sorry to double post.
If i put this command in the right folder "home/xxxx/.bash_logout".
The sudo -k command does not fix this.
I log out, then back in with the same issue, so removed from bashlogoff

> even after 1 hour permission still there

Unable to reproduce and confirm. Pwd is revoked after default time stamp of 15 minutes on Maverick (also after logout-in). As far as I remember it also wasn't an issue on Lucid.
https://help.ubuntu.com/community/RootSudo#Usage

If there isn't a line already for timestamp in sudoers, one could add a line at the end, example:
# Set timeout to zero. Default is 15.
Defaults timestamp_timeout = 0

## Note: the last line of sudoers always must remain empty.
https://help.ubuntu.com/community/Sudoers

Thank you Sam.
I added this to the bottom of the file and left the next line blank.
Just done tests this has fixed my problem.

Ok so now i have a fix for this issue, what i would like to know is what caused this problem in the first place.

I always keep updates updated, they get released i install and this problem is only after the latest updates 31-march2011 to 1-april-2011.

I will forward this fix on to my friends as well.

Also i will tick this solved my problem but i would like to find the cause.

Once again thank you very much for your help.

Thanks Sam_, that solved my question.

"Ok so now i have a fix for this issue, what i would like to know is what caused this problem in the first place."

In that case, you should keep the bug open (by which I just mean, don't mark it as Invalid), and post what you have done, there. Ubuntu developers--and other people who may be able to help--will not necessarily come to this question page, when they see your bug. At minimum, you should summarize the change you made and the effect it had, and attach /etc/sudoers (or a copy with its contents). Make sure that it's clear whether the attached sudoers file is from before or after you modified it by adding the line at the end. If you have trouble attaching that file to the bug report (use the "Add attachments or patch" link on the bug 747158 page), please post here (in this question, since this question already exists) to ask for help with that.

Please also specify what version of sudo you are running, and give at least one concrete example of an application that uses sudo, with which you have experienced this problem (two examples would be even better...and two examples with package versions would be even better). One way to get the version of a package is to run

apt-cache policy packagename

where packagename is replaced with the name of the package. (The name of the package that provides sudo is simply sudo.)

You said that a friend of yours is able to reproduce this bug, presumably on a separate computer. Great. Can you get your friend to come to the page for bug 747158 (your friend should create his or her own Launchpad account) and post there about his/her experiences (including ubuntu release, e.g. 10.10; sudo package version; a copy of their sudoers file; and any other potentially pertinent details)? Preferably you should post the above information there *first*, and then your friend should post additional comments on the bug 747158 page.

I have added the requested files.
The only thing uncompleted is which file caused this, because i do not know.

You still need to:

(1) Summarize the changes you made, and the effect that had. Even with the comment at the end of the attached file, it will not be obvious what's going on with your sudoers file, as things are right now. This needs to be **in the bug report**.

(2) Specify what version of sudo you're running **in the bug report**.

(3) Specify your program examples **in the bug report**.

Also, what do you mean when you say "the only thing uncompleted is which file caused this, because I do not know"? What piece of information are you referring to?

Information that should be "in the bug report" can, if you prefer, be in comments at the bug report (i.e., if you don't want to, you don't have to edit the text of your original bug report, though you can). But it needs to be there rather than here, because the Ubuntu developers who work on this issue are going to look there, and not necessarily here.

> would like to know is what caused this problem

It would be worth an investigation if default behaviour isn't invoked.
That is, when default expiration is 15, as long as the time is no longer than 15 minutes between using 'sudo' in any way, one can use 'sudo' actually endless.

Example on the other hand, open Synaptic, just leave it open and do nothing with it, wait 30 minutes, afterwards I'm still able to install a package without giving pwd again.
When I close Synaptic after 30 minutes without action and reopen I need a pwd again.

If after a logout-in 'sudo' is still available over an hour, I'd assume that it was used in between those 15 minutes over and over again.

However this
> also tried *waiting* and even after 1 hour permission still there

could also allow me to suspect there was/is an active root session and it wasn't terminated correctly. Afaik root sessions need 'exit' otherwise they may run forever.

But you said it was working before the update
> it does not get removed like it normally does.

which brings up the key question, was it certainly different before.
As Eliah mentioned you need to at least define an (not any, at least for the moment) application (package) where devs may reproduce the steps with.
https://help.ubuntu.com/community/ReportingBugs

Regarding your updates, changelog of gdm shows security fix.
http://changelogs.ubuntu.com/changelogs/pool/main/g/gdm/gdm_2.30.2.is.2.30.0-0ubuntu5.1/changelog