User account 'remembers' admin password

Further research has led me to find the cause of this behaviour. It is not a duplicate of bug 87023 as suggested by your email, it is a new and extremely serious bug that will compromise any computer affected with it. Its cause is the package 'kdesudo 1.1.0Ubuntu1'. When this package is removed the default behaviour returns and passwords are requested for every instance of root or admin access. This is how it should be. I suggest you look at this package carefully.

Agreed; this bug is a special case of bug 87023, but only because something is wrong in kdesu/sudo that is causing it to be unable to figure out which tty a command is being run from. This is seen in the sudo cache, as tty "unknown":

 # ls -l /var/run/sudo/kees
 total 0
 -rw------- 1 root root 0 2007-08-16 16:23 unknown

This should normally match the output of "tty". (e.g. "2", etc)

OK I see what you mean.
Like I said, I have removed kdesudu and my functionality has returned to normal and so far I haven't noticed anything untoward from not having the package installed.

Anthony, could you look at this bug? It's milestoned for tribe 6.

Moving milestone to beta.

Will have a look toonight.

I can't see the problem in there...
The fact that the password is stored (as it is for sudo) is a wanted purpose.
Technically kdesudo is only a wrapper for sudo commands, and therefore the password caching functionnalities are still managed by sudo in that case.

I agree that it might dupes #87023 at some points.
The old way to work of kdesu was simply a bug, as kdesu doesn't use sudo the way gksudo for example does, and does respect sudo configuration (sudoers specific rules, caching etc...)
I tested this deeply since yesterday, and everything, at least here, works as expected, or at least works "as if with sudo".

Fix #87023 and you'll fix that one too.

Thank you for your time in looking into this, if having your passwords remembered indefinitely is a wanted purpose on your system then it certainly isn't on mine so we will have to disagree there. I have deleted kdesudo from my system, it works fine and that is the way I intend to keep it.

But once again thank you for your time.

According to my (and others) tests, the password isn't stored indefinitely....
Just 15 minutes as sudo will not prompt for the password in that period.
I tried launching kdesudo commands within the shell every 5 minutes, and also within the kmenu using adept, after the standard 15 minutes caching, I'm prompted again for the password in any case...

You may have an issue with sudo on that point, as the caching is managed by sudo and sudo only, kdesudo doesn't have any mecanism to store passwords, as it is just (once again) a wrapper for sudo commands.
I asked other people to test this too, and all confirmed me that the password indeed isn't stored indefinitely...
Hard to figure out what happens since I can't reproduce....

Also please note that reverting to old kdesu will reintroduce lots of bugs, as it can't use specific sudo settings like NOPASSWD options or allwing specific command to a user/group...
You also can disable the password caching in sudoers by setting timestamp_timeout to 0

Testing this would also be very interesting as this would eventually prove that the problem is in sudo and not kdesudo.

Theorically, with this setting, kdesudo should always ask for a password.

Ah now this is interesting, this is the first time I have ever heard about any time limit on password caching. I have reinstalled kdesudo and straight away the 'remember' function has returned, so I will wait 15 minutes and see if it 'forgets' as it should. However I can assure you that this was not the default behaviour on my laptop before installing the latest kdesudo version - I was prompted for a password every time. It is also intersting that not having kdesudo will disable the NOPASSWD option as I am trying to use this to launch my firewall and couldn't get it to work, perhaps now it will!

Well, I have just waited over 20 minutes and my password is still remembered, I can launch any root program without re-entering it.

Trying to offer my 2 cents, hope this helps.

If you're absolutely sure you waited over 15 minutes, I'd suggest checking '/etc/sudoers' for any special timestamp options. (See 'man sudoers' for further information on the options.) In fact, I'm beginning to suspect you're doing something special in '/etc/sudoers' that's contributing to what you're seeing - either through a genuine bug or an unintended consequence of your tweaks. If you think you could attach the contents of your '/etc/sudoers', that could (possibly) help the developers in trying to track down the issue.

Also, every time you use root capabilities, the sudo ticket (timestamp) (for that tty/pty, assuming we're using the 'tty_tickets' option in '/etc/sudoers') is renewed. Try 'sudo ls -l /var/run/sudo/yourusername/' to see your tickets. While you're at it, check if (as in Kees Cook's comment) one of the tickets is called "unknown". I don't know what effects this would have on the sudo functionality, but it may be an explaining factor for what you're experiencing.

I think it might be something to do with the timing of the password cache. This time I waited 30 minutes and after that time it asked me for a password again so it is working I guess.

/var/run/sudo/username does indeed include a ticket called 'unknown' if you delete it the password is requested again and the 'unknown' ticket returns.

I include the /etc/sudoers as requested, but I am not unhappy with the situation as it is, 30 minutes of remembered password instead of 15 is not going to make a big difference to my usage of the machine.

Thanks for your help, hope I haven't wasted too much of your time.

Contents of /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

Defaults !lecture,tty_tickets,!fqdn

# Uncomment to allow members of group sudo to not need a password
# %sudo ALL=NOPASSWD: ALL

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
username ALL= NOPASSWD: /usr/sbin/firestarter

I still think this is incorrect behavior. kdesudo should act like sudo and gksu, which is to correctly record the tty it is running from when calling sudo. Have an "unknown" tty ticket show up is not correct -- it should be tied to a real tty.

Latest upload fixes the issue