Timeline for Suggested edit to "What does the double-hyphen do in `lxc exec`"
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 10, 2017 at 17:42 | history | edited | Kaz Wolfe | CC BY-SA 3.0 |
added 471 characters in body
|
| May 10, 2017 at 17:31 | history | edited | Kaz Wolfe | CC BY-SA 3.0 |
added 471 characters in body
|
| May 10, 2017 at 8:53 | comment | added | Zanna Mod | 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 | |
| May 10, 2017 at 7:36 | comment | added | Jonathan Y. | Please note my edits to the question. | |
| May 10, 2017 at 7:12 | comment | added | Zanna Mod |
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
|
|
| May 10, 2017 at 7:09 | comment | added | Jonathan Y. |
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?
|
|
| May 10, 2017 at 7:08 | history | edited | Kaz Wolfe | CC BY-SA 3.0 |
added 413 characters in body
|
| May 10, 2017 at 7:05 | comment | added | Kaz Wolfe |
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.
|
|
| May 10, 2017 at 7:05 | comment | added | Jonathan Y. |
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.
|
|
| May 10, 2017 at 7:04 | history | edited | Kaz Wolfe | CC BY-SA 3.0 |
added 375 characters in body
|
| May 10, 2017 at 7:02 | comment | added | Jonathan Y. |
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.
|
|
| May 10, 2017 at 6:59 | comment | added | Kaz Wolfe | @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. | |
| May 10, 2017 at 6:57 | comment | added | Kaz Wolfe |
@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."
|
|
| May 10, 2017 at 6:55 | comment | added | Jonathan Y. |
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."
|
|
| May 10, 2017 at 6:54 | comment | added | Zanna Mod |
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.
|
|
| May 10, 2017 at 6:53 | comment | added | Kaz Wolfe |
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?).
|
|
| May 10, 2017 at 6:51 | history | edited | Kaz Wolfe | CC BY-SA 3.0 |
added 249 characters in body
|
| May 10, 2017 at 6:51 | comment | added | Jonathan Y. |
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 $.
|
|
| May 10, 2017 at 6:49 | comment | added | Kaz Wolfe | @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. | |
| May 10, 2017 at 6:47 | history | edited | ZannaMod | CC BY-SA 3.0 |
edited body
|
| May 10, 2017 at 6:47 | comment | added | Zanna Mod |
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
|
|
| May 10, 2017 at 6:43 | history | edited | Kaz Wolfe | CC BY-SA 3.0 |
I shouldn't be doing Meta when I'm tired.
|
| May 10, 2017 at 6:38 | history | answered | Kaz Wolfe | CC BY-SA 3.0 |