Comment 12 for bug 87023

Revision history for this message
kko (kko) wrote :

Incidentally, I was pondering this too, after my last comment, so I'll comment on these suggestions.

For GUI apps, I agree with you. It should be easy for 'kdesu' or 'gksudo' to:
- Obtain needed privileges and launch the app requiring sudo privileges.
- Immediately afterwards call 'sudo -K' on the appropriate pts.

This should take care of the GUI side of the problem - see further though.

I don't really understand how 'kdesud' is supposed to work. I suppose it just sits there for as long as kdesu is configured to remember the password given to it, and is supposed to catch further launches of 'kdesu'. (It doesn't for me, so I wonder _why_ it is launched at all, but it's a different issue.) I don't know if 'kdesud' needs the ticket at all - according to 'man kdesu' it wouldn't: "The passwords are NOT written to disk, but stored in memory using a special program, kdesud."

If the ticket isn't needed to implement the grace period (i.e. remembering the password for a set time) functionality in GUI sudo apps, the option "--single-shot" definitely sounds like a cleaner way to implement this.

For the CLI, I tend to agree that your suggestions 3 and 4 seem heavy, although number 4 would probably be a good solution. I can't really say anything about suggestion 2.

I came up with the same thought as your suggestion 1 also. Basically, I thought it would be useful, but while trying it out I found a serious drawback. Unfortunately, .bash_logout is only handled for _login_ shells, i.e. it is not executed for inter-active shells from Konsole. (People can also remove '~/.bash_logout', but then it's their choice. I also wondered about the case where the shell (e.g. hanged and) got terminated in an abnormal way and it couldn't execute the logout script - in this case a solution not dependent on the shell would be more reliable.)