This Time Self-Hosted
dark mode light mode Search

Explaining the sudo crapfest

Some of you might have noticed that I’ve been attacked in the past few days over a feature change bug (now unrestricted so you all can judge it for what it was) with sudo.

Let’s try to explain what the problem seems to have been with that bug: the sudo ebuild, since a long time ago, when it was maintained by Tavis Ormandy (taviso, of, among other things, ocert fame), changed the default editor used to nano. The reasoning for this is that you have to have a valid default editor in sudo, and that, after all, is what we ship in the stage3 as default editor, and what OpenRC sets as default editor if the user sets nothing else. I kept the same setting because, well, I could see the point in it; and I’m not a nano user, I don’t have a single nano executable on my main running systems: I use GNU Emacs for all my “heavy” editing, and zile (of which I’m a minuscule contributor from time to time) for the smaller stuff.

This is just the default editor used by sudo, but by no definition the only one. Indeed it’s mostly used in two places: visudo and sudoedit. The former, respects the EDITOR variable, with the usual rules, so if your root user has the EDITOR variable set to anything it’ll be used (this is also not a default, we pass explicitly the --with-env-editor option at ./configure); the only place where it’s not used, by default that is, is if you invoke sudo visudo, but not because we set the default to nano, but rather because sudo by default resets the environment. For what concerns sudoedit, it honours the EDITOR variable by default without us doing anything about it.

Why did we ask sudo to explicitly honour the EDITOR variable? Isn’t that unsafe? Well, not really. First of all, sudoedit is a special command that takes care of allowing an user to edit a file without running anything as root user, so the EDITOR will always be fired up with the same permission as the user running it (pretty cool stuff); and for what concerns visudo… if you allow an user to run visudo, they can easily set up their user to do anything at all, so the permission under which EDITOR runs is pretty much moot.

So why did I refuse to use the EDITOR variable in the ebuild? Well the reason is that I hate that particular dirty hack (because a dirty hack it is). Other ebuilds, like fcron, have been doing it, and I don’t like its use there either. The reason is that it makes package building relying on a variable that is not by default saved anywhere, and that might not really be the same between the build and host machines (just as a further example, I have different EDITOR settings between root and my user… if I were to build sudo right now, with solar’s changes, with my usual method – sudo emerge with env_keep – I would get a build error: EDITOR="emacsclient -c"). If this is really a big concern, the proper solution is to have a proper virtual implementation of the editor: a /usr/libexec/gentoo-editor script that accepts just one parameter (a filename) and relies the call to the currently-selected editor via the EDITOR environment variable. Something like this:

#!/bin/sh

if [ $# != 1 ]; then
    echo "$0 accepts exactly one parameter." >/dev/stderr
    return 1
fi

if [ "x$EDITOR" = "x" ]; then
    echo "The EDITOR variable must be set." >/dev/stderr
    return 1
fi

exec "$EDITOR" "$1"
Code language: PHP (php)

Note: I wrote this snippet right at my blog, I haven’t tested, checked, re-read it at all.

This would allow ebuilds to properly set a default (or even a forced default!) in their configuration stages, without getting in the way of users’ choices.

Now, this is going to require a bit of work; the reason for that is that you have to make sure that it works standalone, that it works with the packages that would like to use it, and most likely you want to make available a “safe-editor” script as well, to enable eventual safe modes where shell-escape (as well as opening random files) is disabled, for those applications that do open the editor as a different user. Since I have never seen much point in pushing this further (I have a long TODO list of stuff much more important for QA, Gentoo and users as a whole), I haven’t done anything about it before, and I didn’t want to start that. But hey if somebody wanted to contribute it, I would have been the first one making use of it.

Now, how much in the way of users I have been by passing --with-editor=/bin/nano in the ebuild? I would sincerely say very little. Do you want to change the default at build time? Take your “How Gentoo Works” handbook out and look up in the index the topic EXTRA_ECONF. It’s a variable. It allows you to pass further options to econf. Options to ./configure (which is what econf wraps around) are positional: the last one passed is the one that “wins”.

Too much work to use EXTRA_ECONF each time you merge sudo?

# mkdir -p /etc/portage/env/app-admin
# echo 'EXTRA_ECONF='$EXTRA_ECONF --with-editor="${EDITOR}"'' >> /etc/portage/env/app-admin/sudo
Code language: PHP (php)

It really isn’t that dificult, is it?

And what really ticked me off is users, which, as precious as they are, are still just users (in this case not even a well-known power user) telling me what the “Gentoo way” is… I think I know pretty well the Gentoo way, given I’ve been a major developer for the most part of the past five years, I’m one of those trying his best to keep everything up to date and maintained, I’m the one who’s running his own workstation to make sure that Gentoo packages do build out of the box.

Comments 10
  1. Where can I find this “How Gentoo Works” handbook? That sounds great!

  2. @above: `man 5 ebuild`. Or failing that, you could probably find it by clicking the “documentation” link on the front page of gentoo.org.

  3. I’ve taken a look at the bug as well. And must say nano as default is not actually Diego’s choice at all. It was decided a looong time ago in a quite heated thread on either -core or -dev (I don’t recall) that it was the best way to go (also specifically in the sudo case). The reasoning is/was quite simple.First, build results depending on the current value of an environment variable is not sound engineering, and against ebuild policy. Second, it was decided that there was never going to be agreement on the “best” editor. Third nano was kept as the default because it is small, straightforward, and easy to get out of when you don’t know it (let’s face it neither vi(m) nor (x)emacs is that easy to get out of). Fourth, by having the EDITOR/VISUAL variables point to nano (which is installed by stage2 as well as stage3) things would be working (although probably not optimal) out of the box.Remember that to not have nano you need to actually remove it from your system. If you are a part of that (probably) much smaller part of the user base, you might have the savvy to actually change the EDITOR variable.That leaves the annoying behaviour of sudo to strip the environment. Well, it seems that what is desired is a way to specify what the environment should be. At least a close approximation can be achieved through ‘alias sudo=”sudo -i”‘

  4. One method that might actually satisfy at least some people (at the expense of others…) is to use –with-editor=”${EDITOR:+${EDITOR}:}/bin/nano:/usr/bin/vi”, potentially adding whatever other editors are deemed appropriate to that list, as –with-editor takes a colon-separated list of editors to use, so you can have fallbacks. If the consensus is that $EDITOR should not be used in the ebuild, then just –with-editor=/bin/nano:/usr/bin/vi:… would work (replacing “…” with a sensible list of editors, for some definition of “sensible”)

  5. Jonathan, that list *only* makes sense if we weren’t to use @–with-enveditor@, but we do. So only ever the first entry would be used.And again EDITOR is respected. If you know how to use sudo, of course.

  6. Good on you, Diego. I’ve never understood what people are talking about when they fling around this fancy-sounding “Gentoo Way” business. As far as I can tell, “Gentoo Way” means whatever the person saying it means.

  7. I saw this a couple of days ago. Read through the bug, read through the reasoning.You’re right, Diego. Hands down.

  8. Umm… Wow! how on earth did that person make such a minor thing to become blown up into such a mess. Clearly you did nothing wrong, Diego. In spite of despising nano and finding it thoroughly irritating I agree wholeheartedly with everything you’ve said on the issue, flameeyes.

  9. Wow. There are idiots wherever you go. They had to lock the gentoo forums topic to stop them from rehashing questions and suggestions made ever so many times.

Leave a Reply to Ivan MiljenovicCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.