1

I'd like to ask for reconsideration on an edit I suggested; based on this meta question, I believe Meta is where such a request belongs.


The post in question is an answer to a question I asked, What does the double-hyphen do in `lxc exec`.

I thought PeterVanHeusden's answer was precise and thorough (also kind, since as he said, there's an argument to be made that my question was a duplicate, only I haven't realized what's actually behind the behavior I was seeing), but it did have some formatting issues.

muru corrected those, but in so doing s/he also made a change which I feel needs to be rolled back:

  1. The question dealt with LXD; PeterVanHeusden made an example involving a shell in both the host and the container, and used the shell prompt to distinguish the two (in a container, typically one gets a root@container:~# prompt). muru felt it was "unnecessarily long", and edited it to a simple $ prompt. Also note that, as KazWolfe mentions below, PeterVanHeusden specified in the text which part works in which context. However, I object to the edit on two grounds: (a) it makes the example less clear, rather than more so (a graphic cue really helps there), and (b) the $ prompt doesn't appear inside a container, because by default one executes commands as root in it (including bash, to get a shell into it); this just adds to the confusion, and the space saved by shrinking the prompt does't help in this case (there's more than enough space in the answer).

Additionally, (something I mistakenly thought muru changed, but was in the original)

  1. A sudo call was used in the example to run the LXD command-line tool lxc, which is redundant. From LinuxContainers.org:

    The package creates a new "lxd" group which contains all users allowed to talk to lxd over the local unix socket. All members of the "admin" and "sudoers" groups are automatically added. If your user isn't a member of one of these groups, you'll need to manually add your user to the "lxd" group.

    This implies that any user able to escalate sudo should already be able to call lxc; moreover, the preferred way of gaining privileges is to add a user to the "lxd" group, rather than using sudo.

    Keep in mind the following two points: (a) using sudo for tasks which don't require it is a bad habit to encourage. (b) A user following this example has already installed LXD and launched a container. All tutorials I've seen, including those on Ubuntu Insights written by Stéphane Graber (project head), use unprivileged containers that don't require sudo. If for some reason users find themselves in a situation where sudo is required to manage LXD, they quite surly already know why and how that happened.

    Hence, I contend that almost everyone, and most particularly novices, are safe to remove the sudo call from the example, and therefore it's better not to include it.

I believe the two reviewers who rejected my edit (to roll these changes back, while keeping the changes to format) might not have looked at the edit history, nor realized that it's (now, partially) a roll-back. I might be wrong, but I believe the answer is better with the two changes I suggested. (To me it is, in any case.)

  • Check the revision history. I did not add a sudo to anything. – muru May 10 '17 at 6:33
  • @muru, wow, sorry, you're right. When I looked at it yesterday, I was sure I saw it was an edit. I'll edit this question to reflect what really happened. – Jonathan Y. May 10 '17 at 6:34
  • For the record, your edit had a +1/-2 split in the review queue. – Kaz Wolfe May 10 '17 at 6:50
2

I'm the other one who rejected your suggested edit.

In my opinion:

The first part of your edit was unnecessary, because the answer clearly states:

The following commands were run in the container

And $ is just a sign that we use to show a comamnd, so muru's edit was fine to me.

For the second part you're somewhat right (about the concept of not using sudo), however the sudo was part of the original answer, and also it was too minor to me.

I rejected your edit mostly because of the first part.

2

I'm one of the people who rejected the review. Hello. Let me try to rationalize my decision based on the data I had at the time I clicked the button according to my own opinion.

And, for the sake of having everything in one thread, here is the suggested edit we are discussing.


Regarding point 1:

To me, it was clear what was and wasn't supposed to run in the container. The context of the commands (in the answer itself) shows that the first block of commands are meant to be run inside the container (emphasis mine):

Consider the following: I created a file /tmp/bar containing the line --foo. The following commands were run in the container:

$ ...

We can usually (safely) assume that anyone reading the answer will actually read it thoroughly. It's the same reason we don't use bold to emphasize things like Ubuntu 14.04. Therefore, the transition from regular-land to container-land is already well-defined.

This concept of "prompt compression" (so, turning user@host:~$ into $) is pretty common, as the additional information is almost always excessive. We don't need to know your username or hostname, we just need to know that we're typing this into a prompt somewhere.

Now, I am fully aware that lxc internally is root and will have a # prompt. This is where clarity becomes important -- # can mean a comment just as easily as it means a root shell. In this case, it really doesn't matter. You enter a container, you get a root shell automatically, no other actions required. And, as we've already entered the container, it doesn't matter much.

We can change it to # (although that may still cause some confusion whether it's a comment or not), but we shouldn't include the username/hostname, just for the sake of brevity. It's often a good writing practice to say what you need to say as clearly as possible, using as few words as possible.

However, I do agree that the transition out of the container should be made more clear. I can edit that in, or let you do it. It doesn't really matter. Just some blurb somewhere saying that the grep command is meant to be run on the host machine.


Regarding point 2:

I checked the edit history of the post in question, and did not see muru add sudo. It was present in the original post.

However, even if it was not, it would have still been a sensible addition. Not every user automatically has permission to manage lxc (see here), and we can't make that assumption. It's safer to add sudo to the command and let someone take it out on execution if they feel is unnecessary.

Ok, I was wrong here. Turns out, I don't know how lxc and lxd usually work with permissions. Therefore, I (and I think most editors) will tend to defer to the OP's knowledge being correct unless they know otherwise. Actually doing the research into lxc and doing recon with this shows that your edit is technically accurate (and should have been approved, at least on that front). With that in mind, sorry. I screwed up here.

That said, removing sudo from the OP's post does change the post's intent (something edits typically shouldn't do), and therefore should be discussed (at least briefly) in the comments section about whether sudo is (or isn't) necessary instead of leaving it up to the editors to know. See Zanna's answer on editing code. Personally, I'd consider removing sudo to fall under the "simplification" category as opposed to an error correction.

  • 2
    I disagree with your last point - safer NOT to add sudo and let the user add it when they get nah mate, you can't do that – Zanna May 10 '17 at 6:47
  • 2
    @Zanna From a security perspective, yes. But, this is a usability question with a relatively new user. It's best to not get them into the whole discussion about root and privilege escalation (when, how, why, etc.). If they want to learn about all of that and how to do permissions properly, they're more than welcome to. – Kaz Wolfe May 10 '17 at 6:49
  • KazWolfe I'm the OP; I happen to agree with @Zanna, which is why I suggested the edit. Regarding the first point, by the same logic you use in the second, one would never get a $ prompt inside the container unless one actively did some fancy maneuver particularly for that effect; it's illogical to edit the # prompt into a $. – Jonathan Y. May 10 '17 at 6:51
  • Regarding the substitution for the full shell down to just $, I can't speak for muru but I can guess. Really, it's just a stylistic choice to say "this is a shell" - with a # you can be left guessing (is this a root shell? is it a comment?). – Kaz Wolfe May 10 '17 at 6:53
  • not only from a security perspective I think... many commands will not work properly (because of the different path) or cause future problems (because graphics) when run with sudo. For new users - not good to encourage the habit of constantly using sudo. – Zanna May 10 '17 at 6:54
  • KazWolfe, that's why the Peter and I actually had a root@myContainer:~# prompt in place. There's more than enough space for it. To quote what I said in chat: "it's mentioned in the surrounding text, but that's no reason to make it less graphically clear in the example; the change hurt the clarity of the answer, rather than improving it." – Jonathan Y. May 10 '17 at 6:55
  • @Zanna: In which case, we handle it on a case-by-case point at the discretion of the OP and/or editors. In almost all cases though, environment data (that includes the path) is preserved through sudo. Similarly, lxc is typically a utility run by a root user. It's (relatively) safe to assume that this conforms to most uses of a command. You wouldn't say "Run rm /some/root/file and if that doesn't work prepend the command with sudo," you'd just say "Run sudo rm /some/root/file." – Kaz Wolfe May 10 '17 at 6:57
  • @JonathanY. Well, this entire post is just my opinion and rationale for making the choice to reject the edit. I'm sure others have their differing opinion. To me, it was perfectly clear what was and wasn't supposed to run in the container vs the shell. Therefore, I sided with muru. – Kaz Wolfe May 10 '17 at 6:59
  • KazWolfe lxc, to the best of my knowledge, is far from "a utility [typically] run by a root user". It's the LXD command-line tool, and was designed to be fully functional as a regular user. – Jonathan Y. May 10 '17 at 7:02
  • This isn't about whether your review decision was appropriate; of course it was. It's about changing your mind. If you still feel like $ are better, and so are the sudos, then that's just fine, although I'd like to talk about it. – Jonathan Y. May 10 '17 at 7:05
  • At the same time, though, the docker command works in much the same way. It's perfectly usable as a non-privileged user if you're working on a non-privileged container or you're in the docker group. But, not everyone has both of those cases in play. – Kaz Wolfe May 10 '17 at 7:05
  • To get a privileged LXD container, one needs to actively change the profile or properties. It stands to reason that these users will know they have to also use sudo. Why should that be what we present to the typical user, relying on the tutorials (published by the LXD team on Ubuntu's site), which all use unprivileged containers? – Jonathan Y. May 10 '17 at 7:09
  • The path is not preserved, generally speaking, and one has to make rather a convoluted command to preserve it. See the sudoers file - mine has secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin". To preserve it you need to run something like sudo env PATH=$PATH command – Zanna May 10 '17 at 7:12
  • Please note my edits to the question. – Jonathan Y. May 10 '17 at 7:36
  • 1
    I am not saying we should never add sudo; when we know it's needed (or better than the dodgy alternatives) then we should add it. I added some in an edit myself earlier. But as a general principle "add sudo to be on the safe side" - I say nope – Zanna May 10 '17 at 8:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .