@EliahKagan sorry, yesterday I meant to make a small comment on this, but I got distracted by making cookies and pie

I was going to say that the most interesting (though not necessarily useful) part of the background to me is why Ubuntu decided to patch sudo in this somewhat annoying way in the first place.

That might be out of the scope of this Q&A

I like the list very much as it answers everything important that comes to mind

Are you planning to expand on the last point later in the answer?

@Zanna If you mean the currently bad "This can also get messy" paragraph, yes.

@Zanna I plan to mention something about it and link to the mailing list discussion and bug report that led to that change which has now been undone for 19.10 and on. Beyond that, not really. Not beyond "Sometimes...it is appealing to have that program use your settings." That's pretty much the entirety of the reason Ubuntu patched sudo to keep the very old sudo behavior of preserving $HOME, as far as I can tell.

@EliahKagan To clarify, this is the draft I have now:

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…

@EliahKagan I actually meant the last point in the list. Sorry for being unclear!

The point about most commands not behaving differently?

@EliahKagan someone said it might be nice so they went with that?

@EliahKagan specifically I mean why people who depend on this behaviour for some reason might not want to use the sudoers file to override it

Oh. Yes.

In the specific cases users want $HOME not to be reset, they can use:

Simply I was curious about that and wanted to know more

sudo --preserve-env=HOME ...

Or (though I don't know if I'll mention this in the answer):

sudo HOME="$HOME" ...

Which in most cases can be written:

sudo HOME=~ ...

That covers specific cases of commands where it is desired for $HOME not to be reset.

For editors, the solution is sudoedit.

So, someone might want to edit files as root with their own vim configuration by running:

sudo vim ...

But this also uses the non-root user's vim configuration, because it runs the editor as the non-root user, then updates the file at the end:

VISUAL=vim sudoedit ...

Or sometimes it is sufficient to use:

sudoedit ...

There are other techniques, but I don't want to make it into a post about running text editors.

I don't really have anything deeper to say about it. Basically, I think people should use --preserve-env=HOME in the specific cases when preserving $HOME is desired and not otherwise.

@EliahKagan Haha yeah

I was wondering why they wouldn't want to use sudoers

My thought is, they would not want to because the current behaviour would be preserved by that and it's mostly annoying

Yeah. I think most people probably don't like the current behavior.

Though I think it's possible to be unaware of it.

I mean, I do use some other Unix-like operating systems that have sudo. I did not know until recently that sudo has been resetting $HOME on all those systems for years.

@Zanna I don't fully understand the reasoning.

The mailing list discussion "$HOME changed by sudo," back in February 2011, starts here.

Multiple people mentioned that it caused them problems (or at least inconvenience) using pbuilder.

Anyway, that discussion led to--or in any case preceded and was referenced in--the April 2011 bug report HOME environmental variable no long preserved with sudo by default.

I'm not sure what Steve Langasek was referring to in comment #2 in that bug report.

@EliahKagan yeah, I had no idea!

The new bug report, Ubuntu patch to add HOME to env_keep makes custom commands vulnerable by default, focuses (and originally was just about) on why the behavior of not resetting HOME is a security bug.

The specific changes it recommends are not exactly the same as those that were adopted. It recommends:

> The patch should be removed and the default /etc/sudoers should explicitly add HOME to "env_keep" for the "allow admins to run any command as root" entries, to get the desired behaviour without creating security issues for other sudoers commands.

This part was done (for 19.10):

> The patch should be removed

But this was not:

> the default /etc/sudoers should explicitly add HOME to "env_keep" for the "allow admins to run any command as root" entries

That is, if the specific (combination of) changes recommended in the bug report were made, it would be much harder to notice the difference, because the behavior in the common case of a member of the sudo group running commands (as root or another user) with sudo would still preserve HOME.

I think it is good that the change with the bigger effect--making it so that doesn't happen either--was made. Also, that change involved fewer modifications than the bug report's recommendation would involve. Also, the bug report's recommendation wouldn't take effect for everyone upon upgrade; a user who had modified /etc/sudoers and then upgraded would, depending on how they upgraded, either be asked what version of the file they wanted to keep or would simply be left with their version.

@Zanna Yeah, actually that's the correct answer.

People generally don't want $HOME preserved. The common cases are actively wanting it not to be preserved (in which case it must not be preserved) and not wanting to have to care if it is preserved (in which case it must not be preserved).

I mean, having it preserved by default goes against the explanation, common in the Ubuntu community, that sudo is a safe and easy alternative to enabling the root account.

yeah

@EliahKagan I think it's good too

it would feel a bit wrong to encourage everyone to edit /etc/sudoers

although I guess I encourage everyone to add insults

Well, people who had not edited /etc/sudoers would receive the updated conffile.

@Zanna Yeah, but that's not the way I'd recommend adding insults.

It can go in a file created in /etc/sudoers.d/.

oh, yes...

sudo visudo -f /etc/sudoers.d/tell-it-like-it-is

nice!

It can be called anything in place of tell-it-like-it-is, so long as the name does not contain ~ or .. Also, I don't recommend calling it README. There is already such a file, and I'm pretty sure you can actually put configuration in there and it is used, but I don't recommend it (except to try it out).

@Zanna I mean, you still need to write the contents of the file.

But it's the same as if you put it in /etc/sudoers:

Defaults insults

@EliahKagan I realise that XD

I hadn't noticed visudo had an -f flag or thought of using separate files, though that's obviously a great idea

Yeah, the directive

#includedir /etc/sudoers.d

at the end of Debian's (and thus Ubuntu's) default /etc/sudoers file causes files in /etc/sudoers.d/ to be used as well.

@Zanna By any chance, did you check my website ?

no I didn't... I looked at your post about regular expressions a while ago, but it looks different to how I remember

@Zanna Ok if you get time, please check :)

sure! Anything in particular you want me to see or do?

@Zanna Ummm.. Not anything in particular, but only if you have enough time, you scan scan my whole site and blogs and can provide me feedback :P

ok :)