Comment 1 for bug 87023

kko (kko) wrote :

As this issue seems somewhat hard to remedy completely, I decided to comment on possible remedies separately.

It would seem beneficial that unused tty_tickets from '/var/run/sudo/yourusername' should be cleared. More specifically, the tickets for such tty's and pts's that _are not in use_ at any point in time should be cleared.

Now, what process could be responsible for doing this?

A. The kernel and "devpts", which is responsible for assigning new pts's at '/dev/pts/*'. It could be argued that this would be the right place, to tackle the authorisation issue at a low level. It could also be argued the opposite, that authorisation issues do not belong here, that it is not the kernel's job to do things for sudo. This would mean that this should be handled in userspace.

B. A root level "sudo daemon" that would keep an eye on tty's and pts's on one hand and sudo's tty_tickets on the other hand. Whenever a terminal or a pseudo-terminal is freed, the daemon would clear the appropriate sudo tty_ticket for all users, and possibly make a note in a log. (The tty's probably would need to be handled differently than the pts's.)

C. For graphical applications requiring sudo access, the application that granted the access could also clear the ticket when the sudo capability isn't needed anymore. (E.g. 'kdesu' or 'kdesud'. It seems the 'kdesud' is used for caching the password given to 'kdesu'.)

D. A work-around is to use "timestamp_timeout=0" in '/etc/sudoers', but this takes away a usability feature from sudo.

A couple non-working "solutions" follow:
E. "The command 'sudo' should be responsible for clearing the ticket." This can't be done, because sudo is not running when the terminal is freed.
F. "The terminal or 'bash' should be responsible." This can't be done because the terminal or the shell are not root-level processes, and so can't remove root-owned tty_tickets.