@Zanna 19.10 is out so the time for fun has arrived. :)

I've been intermittently writing bits of a Q&A about it. I'm not sure how much to describe in the question and how much to describe in the answer. But I am inclined to think that describing my original observations, plus information about how they still hold now that Ubuntu+1 is out, is justified in the question, even though that would make it longer than the question portion of many planned-out self-answered questions.

In case you're interested (since we discussed it before when 19.10 was Ubuntu+1), right now I have this draft for the question and this draft for the first ~25% of the answer (more than 25%, if I can write better and figure out what's worth omitting, though I don't think that beginning section will itself get much shorter).

@EliahKagan hahaha:D

I will have a look at your draft shortly!

@Zanna Thanks! There is no hurry. The answer draft is much in need of expansion and likely other improvements. Also I shall often be afk, sometimes for long periods. :)

@EliahKagan looks very good so far!

The question feels long but it all seems to the point

The stuff currently in the answer is very illuminating. Since I'm currently getting a cold and feeling groggy I am in a good position to determine that it's very clear and easy to read!

Thank you for explaining. I might need to read it thoroughly again.

@Zanna I could shorten it by removing the stuff about --preserve-env.

I'm thinking I should probably do that. That should go in the answer, because people who want to make 19.10 work like previous releases will look in the answer to find out how (and I do plan to cover that), but most people should just use --preserve-env=HOME in specific cases rather than doing that.

I am wondering if I should remove the italicized paragraph at the bottom of the question. As written, it's not really correct -- this isn't really intended as a canonical question, because there are not yet (as far as I know) any questions asked about this. My motivations for having that part are

(a) defensive question-asking, i.e., fear that people will vote to close the question as OT bug, but I should probably just let that happen and try to get it reopened if it is wrongly closed for that reason, and

(b) preventing people from thinking that sudo echo "$HOME" showing their home directory is related to this.

@Zanna I hope you feel better soon even though it may lessen your powers of proofreading. :)

@Zanna Should I try to split the stuff about always_set_home between the question and the answer? Like, I could say in the question:

Instead of the much longer thing I now have:

At first I thought this might be due to [updated configuration files][2]. I can make it so `sudo` behaves this way on earlier releases--always resetting `$HOME` unless overridden by `--preserve-env` or `-E`--by editing `/etc/sudoers` (`sudo visudo`) or a file in `/etc/sudoers.d` (e.g. `sudo visudo -f /etc/sudoers.d/always_set_home`) to add:

    Defaults        always_set_home

But I checked, and `always_set_home` does not appear in any `Defaults` line in the 19.10 `sudoers` file.

But then I think I'd want to cover always_set_home in the answer. It may be worth it to make the question shorter, though.

I plan to move the messages about the sudo / $HOME Q&A to the island soon.

← 74 messages moved from Raiders of the Lost Downboat

@EliahKagan good idea

Now that I've moved the conversation here, I won't be distracting from stuff that's on-topic in the Downboat by just posting the old Q and A drafts here, where I think they are much easier to consult than in the pastebin.

In Ubuntu releases prior to Ubuntu 19.10 Eoan Ermine, when I run a command with `sudo`, that command receives *my home directory* in the `$HOME` environment variable. This is the behavior I have long expected and [warned other people about][1]. If I want `sudo` to reset the `$HOME` environment variable, so that it refers to the target user's home directory instead of my own, I have to pass the `-H` option (or `-i`, though that does more).

<!-- language-all: lang-bash -->

    ek@Kip:~$ lsb_release -d

For years, Ubuntu has provided a patched version of `sudo` that preserves `$HOME` by default. Besides Ubuntu and its derivatives, very few other operating systems (perhaps no others) do this. It has been decided that this causes more problems than it solves, and starting in Ubuntu 19.10, `$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 indeed be used in case…

Here's the question with those removals applied:

In Ubuntu releases prior to Ubuntu 19.10 Eoan Ermine, when I run a command with `sudo`, that command receives *my home directory* in the `$HOME` environment variable. This is the behavior I have long expected and [warned other people about][1]. If I want `sudo` to reset the `$HOME` environment variable, so that it refers to the target user's home directory instead of my own, I have to pass the `-H` option (or `-i`, though that does more).

<!-- language-all: lang-bash -->

    ek@Kip:~$ lsb_release -d

yes I think the shorter version works well

@EliahKagan :D thanks, I feel a bit better

@Zanna Now the question on my mind is, can I manage to not write most of what I planned to write in the answer, and still make an answer that's as good as or better than what I had originally envisioned?

Like, if I add links to support everything in the material I've already written for the answer, how much more is needed?

Would the answer really benefit from a history going back to the change made in sudo upstream?

it could be a very interesting history...

I'm having some trouble, going just by sudo.ws/changes.html, in figuring out exactly when the change was made upstream.

hmm

if the changelog is as difficult to understand as the man page I won't be able to make much of it

The changelog is easier.

@Zanna This seems to be the key historical information.

The bug report associated with the 19.10 change ends with:

> 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.

But I am pretty sure only the first of those two changes has been made.

The author of the bug report was concerned specifically about the security of commands run by users who are permitted to run specific commands but not others with sudo. But the change was made for reasons beyond that, and so the stronger effect of simply never preserving the value of HOME (unless the user acts specifically to make this happen) was chosen.

/etc/sudoers in the eoan git repo does not contain env_keep or otherwise mention HOME (and it still contains env_reset). To double check, I just installed from the 19.10 live-server image on a virtual machine. Neither the live-server image's own /etc/sudoers nor the one it installs to the target has env_keep (and neither has a file in /etc/sudoers.d/ with it).

I have also created an LXD container from the official 19.10 image. As expected, it doesn't have env_keep in /etc/sudoers (or in any file in /etc/sudoers.d/). All the systems/environments have the new (to Ubuntu) behavior of resetting $HOME even when -H or -i is not used (as a non-root user, I tested printenv HOME vs. sudo printenv HOME on all of them).