visudo isn't a fork, it just locks the sudoers file against concurrent edits, runs whatever standard editor you want, waits for it to finish, and validate the new file before committing it to the real location.
I can agree that process is too complex, but they're not maintaining a fork of vi for that purpose.
> and validate the new file before committing it to the real location
Controversial take: i think that it'd be really good to have EVERY configuration file have something like that. For example, if i'm working on a long bit of configuration for fstab, cron, Apache2, Nginx, Tomcat or any other pieces of software, i'd want to see whether everything i've written will be considered valid ahead of time, e.g. a "dry run" of sorts. A bit like we have language servers for VS Code, we could have validation servers as well, for configuration.
That said, i don't think we'll ever have that, since it's easier to just write code in an ad-hoc manner, as opposed to extracting validation of configuration as a separate bit of code that can be called from some CLI, not just at runtime, especially since many configuration files allow nested includes.
Regardless, thinking more about models and validation methods would be nice, e.g. XSD. If we leverage type systems in programming languages, we might as well do that at an operating system level - something like shellcheck built in. A validation handler for every file type.
$ docker run --rm nginx:1.20.2 nginx -t -g "daemon off;"
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
On the one hand, I get that not everybody needs all the features of sudo, but on the other.... Sudo is way more useful than doas. If you really go through all its functionality, you start using it in ways you didn't think to before.
You can have a custom AuthZ solution and automatically inherit sudo permissions based on groups. It supports a configurable askpass. You can background jobs, change working directory, selectively pass or set environment variables, set $HOME, use a login shell, preserve origin groups, use a chroot, read a password from STDIN, override the shell, set a timeout. And of course the sudoedit features.
I know we all like programs that "do one thing well", but sometimes the best way to support all the use cases we want is a big honking program.
> I feel that it's better than `sudo -e`, but would love to see an example where `sudo -e` is better.
It is way worse than `sudo -e`, because it runs the entire editor as root, whereas `sudo -e` runs a few file copies / move as root. So `sudo -e` has a significantly lower amount of stuff in the "secure zone", and thus, much in the same way `doas` is more secure than `sudo`, `sudo -e` is a lot more secure than running the entire editor.
It also works with anything you can set as $EDITOR.
Some editors (like vscode) will outright refuse to run as root by default.
Actually, `sudo -e` forces VIM onto innocent users. You are free to `sudo nano` if that's your preference.
> `sudo -e` runs a few file copies / move as root.
Interesting, thank you, I did not know that the editor is not run as root with -e. So presumably that means that it will have my environment, e.g. will run my .vimrc? Though that could be an attack vector too.
> Actually, `sudo -e` forces VIM onto innocent users
No, it does not. It runs whatever EDITOR is set to (technically the first set of SUDO_EDITOR, VISUAL, and EDITOR).
> So presumably that means that it will have my environment, e.g. will run my .vimrc?
That is correct.
> Though that could be an attack vector too.
Only on the specific file, which would usually be a lot more noticeable unless the attack specifically manages to recognise and target sudoedited files while closing the buffer.
> Only on the specific file, which would usually be a lot more
> noticeable unless the attack specifically manages to recognise
> and target sudoedited files while closing the buffer.
I've seen far more sophisticated attacks than that. Though vimscript itself is kind of a barrier to entry ))
Which is arguable an attack vector. Depending on how careless the user is, there is far more likely a chance that malicious code is found in .vimrc than is found in the VIM executable.
They’re probably referring to the attack surfaces of the extensions you have loaded in your normal configuration, as opposed to the probably empty environment of root.
I actually would prefer the editor binary to run as root, rather than have my VIM config available. Any malware that could replace my system VIM would already have access to do whatever it wants to anyway. But malware to alter my own VIM configuration has a much lower barrier to entry.
> The temp file is a feature but not essential to getting work done.
The entire point of sudoedit is to reduce the attack surface, without that it's absolutely useless since you can just `sudo` whatever editor you prefer.
Sure this is a nice and concise (yet somewhat trite) example, but this can be done easily with 1 line in sudoers as well (and is usually configured like this by default anyway).
Not that doas isn't great, but this particular reason isn't that compelling (to me).
That's the entire configuration. It does not need documentation that starts with a quick introduction to EBNF, the whole thing it's about as simple as you could possibly make it. Granted, if you're just doing small edits to existing sudo config it might not matter too much, but I find it appealing to be able to read and understand the entire configuration file and add new configuration easily.
