« first day (799 days earlier)      last day (1600 days later) » 

4:38 AM
@Zanna I think that, at some point, there was a rumor that graphical applications might have to run with $HOME preserved, based on the idea that they would might have to be able to access .Xauthority or .ICEauthority in the home directory of the user running the X session.
I don't know if that ever had basis in truth. I hope not, since graphical applications that use files in one's home directory are specifically the ones likely to cause trouble if $HOME is preserved. In any case, I don't have any reason to think this view influenced any decisions made by Ubuntu developers at any point. But I've heard it expressed in some old forum posts.
So, the possibly too long history section that I should possibly remove entirely is possibly finished.
For years, Ubuntu has [shipped a patched version of `sudo` that preserves `$HOME` by default][1]. Besides Ubuntu and its derivatives, [very few other operating systems (perhaps no others) do this][2]. It has been [**decided that this causes more problems than it solves**][3], and [starting in Ubuntu 19.10][4], `$HOME` is no longer one of the few environment variables `sudo` preserves.

In terms of *what* the change is and how it affects users, the key points are:

- **As of Ubuntu 19.10, <code>sudo *command*</code> does what <code>sudo -H *command*</code> does in previous releases.** It can
I'm wondering how valuable this will be once I have the other sections that will precede it. In particular, don't I need to explain env_reset anyway? It is reasonable for me not to cover that except in the history section?
I'm not sure what to do. I can't tell if my affinity for this history section is just because it's most of what I've written, or if there is actually a good reason to have it. The other thing is, should it be a separate answer? Like, I can post it separately, afterwards, as a CW answer. Of course, I only want to do that if the main answer is complete without it.
 
5:10 AM
I thought of it being a separate answer too
I'll be back later
 
Ok
(I'm also going afk for a while.)
 
 
2 hours later…
7:37 AM
The history is reading really well to me
It doesn't seem too long or seem to be criticising anyone
It gives me the impression that patching sudo to preserve HOME was a reasonable thing to do, and the decision to change back to keeping the upstream behaviour came about as issues emerged...
Our /etc/sudoers has Defaults env_reset, but if we comment or remove that, nothing will actually change?
 
 
1 hour later…
9:07 AM
@Zanna I don't think it was the right thing to do.
@Zanna Correct.
@Zanna Yeah, it doesn't mention anyone by name, mostly for other reasons than that--it keeps things shorter by omitting the names and not having to write in a longwinded manner that avoids ambiguities about who said or did exactly what. I'm worried that this doesn't make the history part clear enough, though. Like, if this post were primarily a work of history about Ubuntu, then I would want to identify at least the major figures (though in some cases it's subjective who they were).
@Zanna I'm pleased!
If there's a reasonable way to include it, I'm quite tempted to do so, because I don't want to have to redo large amounts of it in other parts of the answer.
I think maybe I do not need to mention env_reset elsewhere in the answer.
 
@EliahKagan that seems bad
 
@Zanna Why, and which thing?
That it has the line, or that removing or commenting it out doesn't change anything?
 
That is, it seems more astonishing that it's there doing nothing and removing it would have no effect, than it not being there at all would be
 
Yeah, I've seen arguments that one should not explicitly enable env_reset in one's sudoers file.
(In the context of writing one's own sudoers file, as one does on some systems.)
 
9:32 AM
I don't know why /etc/sudoers in Debian and Ubuntu has an explicit Defaults env_reset line, but arguably it has the advantage that it makes it easier to know how to turn off that behavior, by adding a ! before env_reset.
I don't think that's a very good reason, though. People would likely not know to do that and assume that commenting it out would work. Also, most changes to sudo's configuration are best made in files added to /etc/sudoers.d/, which having an explicit Defaults env_reset in /etc/sudoers somewhat discourages (by encouraging modifying that line).
 
@EliahKagan that makes some sense
@EliahKagan yeah
 
9:48 AM
How does sudo -e / sudoedit / visudo split the value of SUDO_EDITOR (or VISUAL, or EDITOR) into arguments? Does it just match [[:blank:]]+ as a delimiter?
 
10:05 AM
I was reminded that I had wanted to find out about that a while ago (and then forgot about it), as I was experimenting with editing sudoers files.
ubuntu@eoan:~$ sudo cat /etc/sudoers.d/keep-home
Defaults        env_keep+="HOME"
ubuntu@eoan:~$ sudo printenv HOME
/home/ubuntu
ubuntu@eoan:~$ sudo SUDO_EDITOR='sed -i 1s/^/#/' visudo -f /etc/sudoers.d/keep-home
ubuntu@eoan:~$ sudo cat /etc/sudoers.d/keep-home
#Defaults       env_keep+="HOME"
ubuntu@eoan:~$ sudo printenv HOME
/root
I realized that I don't know how to modify that so it puts a space after #, because that would be the end of the code argument to sed.
Of course, sudo sed -i can be used directly to edit a sudoers file, but like with sudo vim, it's not a good idea because there's no syntax checking.
ubuntu@eoan:~$ sudo SUDO_EDITOR='sed -i 1s/^/?/' visudo -f /etc/sudoers.d/keep-home
>>> /etc/sudoers.d/keep-home: syntax error near line 1 <<<
What now? q
Options are:
  (e)dit sudoers file again
  e(x)it without saving changes to sudoers file
  (Q)uit and save changes to sudoers file (DANGER!)

What now? x
 
 
10 hours later…
7:55 PM
@EliahKagan That's not actually important for the answer. It's just something I've been curious about.
 

« first day (799 days earlier)      last day (1600 days later) »