Bugzilla – Bug 514
move /var/lib/sudo back to /var/run or /run
Last modified: 2014-05-07 13:28:20 MDT
Created attachment 316 [details] patch which makes it posible to use /run/sudo in stead of /var/lib/sudo this was initially changed because "This prevents users from receiving the sudo lecture every time the system reboots" but if the lecture should be displayed is AFAIK user data and should be in the users $HOME (touch a file $HOME/.sudo or something) this way the user/nonvolatile data gets split from the volatile timestamp data which then van be moved back to /var/run (or /run on current linux machines). this will remove the need for /usr/bin/find /var/lib/sudo -exec /usr/bin/touch -t 198501010000 '{}' on every boot a proposed (untested) patch is attached (I am not a c guru)
I have been considering moving the lecture status into its own file. Putting this in the user's homedir has some disadvantages though. If the user's homedir is not available (or not writable) they would now get lectured where before they would not. Also, if the homedir is NFS mounted and the NFS server is unreachable it may no longer be possible to use sudo, which is a real concern. I don't know why you would need to touch the sudo timestamp files on boot. Sudo is capable of determining the boot time on most systems and will not honor a timestamp that predates the system boot time.
(In reply to comment #1) > I have been considering moving the lecture status into its own file. > Putting this in the user's homedir has some disadvantages though. If > the user's homedir is not available (or not writable) they would now > get lectured where before they would not. Also, if the homedir is NFS > mounted and the NFS server is unreachable it may no longer be possible > to use sudo, which is a real concern. what it actually comes down to to me is whether this is user data or not, and if it is it is clear to me where it should reside, in the place where all user data belongs. ($HOME) but we could also use hybrid logic, which when chosen for having the timestamps in /var/run and in the case $HOME is not available will indeed result in the user beeing given a lecture the first time after boot, but not afterwards (because of the timestamp in /var/run/sudo), which sounds like a decent fallback solution to me. we could also make timedir settable/overwritable in the sudoers file, this way the sysadmin has controll over whether he would likes this data to persist /var/lib/sudo or not to /var/run/sudo, which when chosen for /var/lib/sudo should result in the current behaviour. (still have to look at the code for this) but indeed, having $HOME unavailable (NFS unreachable,...) should not block one from using sudo, but i think one extra lecture in this case is acceptable. > I don't know why you would need to touch the sudo timestamp files on > boot. Sudo is capable of determining the boot time on most systems and > will not honor a timestamp that predates the system boot time. thanks for pointing this out, this behaviour is propably a bug in the debian package (which includes an initscript doing this), i will file it there
In sudo 1.8.10 the time stamp files have moved back to /var/run/sudo and a separate file is used for lecture status (still in /var/lib/sudo). There should no longer need to be an init script on systems that clear /var/run on boot (basically everything except HP-UX and AIX).