Trying to edit crontable via "crontab -e" and sudo results in error Reproducible: Always Steps to Reproduce: 1. execute "sudo crontab -e" as a user with appropriate permissions 2. enter password if needed Actual Results: yzhao@sui yzhao $ sudo crontab -e /bin/sh: line 1: /bin/vi: No such file or directory crontab: "/bin/vi" exited with status 127 Expected Results: a vim instance is launched which allows me to edit my crontab Error does not occur if "crontab -e" is used from a root shell. Installed packages: [ebuild R ] sys-process/vixie-cron-4.1-r7 -debug +pam (-selinux) 57 kB [ebuild R ] app-admin/sudo-1.6.7_p5-r2 +pam -skey 341 kB [ebuild R ] app-editors/vim-6.3.068 -acl -bash-completion -cscope -debug +gpm -minimal +ncurses +nls +perl +python -ruby (-selinux) -vim-with-x 0 kB Linux sui 2.6.11-hardened-r1 #1 Thu Apr 28 09:39:11 PDT 2005 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20041102-r1, 2.6.11-hardened-r1 i686) ================================================================= System uname: 2.6.11-hardened-r1 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 28 2005, 17:31:20)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mtune=pentium3 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mtune=pentium3 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://modzer0.cs.uaf.edu/public/gentoo/ http://gentoo.asgn.ca/" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib acpi apache2 apm avi berkdb bitmap-fonts cjk crypt cups curl emboss encode foomaticdb fortran gdbm gif gpm gtk gtk2 hardened imlib ipv6 java jpeg libcaca libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg mysql ncurses nls nptl nptlonly oggvorbis opengl pam pdflib perl php png ppds python quicktime readline samba sdl slang spell sse sse2 ssl svga tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb xml2 xmms xprint xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Forgot to mention that the EDITOR environment variable is set to "/usr/bin/vim"
(In reply to comment #1) > Forgot to mention that the EDITOR environment variable is set to "/usr/bin/vim" Well, it does not matter, same error with EDITOR=/bin/nano or whatever else...
sudo resets the EDITOR variable to one set at compile time as security measure ("EDITOR=/bin/rm -rf /" sudo crontab -e anyone?). The proper way to fix this would be setting a sane (with vi, vim, nano, emacs and perhaps some others) --with-editor in the sudo configure. Perhaps allowing a "SUDO_EDITORS" variable in make.conf for more. http://www.sudo.ws/sudo/install.html has some info. If you're allowing full sudo access to wheel, you can set something like this in sudoers as workaround: # Uncomment to allow people in group wheel to export variables Defaults:%wheel !env_reset But read the first paragraph of this comment first. Only use this after realizing what gaping security hole you're creating.
Uhm. Allowing a user to run vim or vi via sudo gives them the ability to run *any* command as root.
This is a bug in the sudo ebuild, the default editor is forced to /bin/vi when env_reset is in effect, which may not be available. This is fixed in sudo-1.6. 8_p8-r3. Please try it out and confirm this fixes the issue. (In reply to comment #4) > Uhm. Allowing a user to run vim or vi via sudo gives them the ability to run > *any* command as root. you mean via :!foo? that's what noexec or sudoedit are for :)
(In reply to comment #5) > This is a bug in the sudo ebuild, the default editor is forced to /bin/vi when > env_reset is in effect, which may not be available. This is fixed in sudo-1.6. > 8_p8-r3. Nope, no good: yzhao@sui ~ $ sudo -V Sudo version 1.6.8p8 yzhao@sui ~ $ sudo crontab -e /bin/sh: /bin/vi: No such file or directory crontab: "/bin/vi" exited with status 127
vi seems to work for me now, but not my $EDITOR (nano).
Tavis, reassigning this to you as this definitely isn't a cron-related bug.
My mistake, it wasnt the sudo bug I was thinking of, it's definitely a cron bug, if EDITOR and VISUAL are unset it uses /bin/vi as the default: from pathnames.h: ... /* what editor to use if no EDITOR or VISUAL * environment variable specified. */ #if defined(_PATH_VI) # define EDITOR _PATH_VI #else # define EDITOR "/usr/ucb/vi" #endif ... from crontab.c: ... if (((editor = getenv("VISUAL")) == NULL || *editor == '\0') && ((editor = getenv("EDITOR")) == NULL || *editor == '\0')) { editor = EDITOR; } ... I guess you guys should switch this to /bin/nano, to make sure a default editor is always available.
just - #define _PATH_VI "/bin/vi" + #define _PATH_VI "/bin/nano" in paths.h should do the job.
(In reply to comment #9) > I guess you guys should switch this to /bin/nano, to make sure a default editor > is always available. Hmm, I really think that hardcording an editor in such way is an ugly hack. :/
(In reply to comment #11) > Hmm, I really think that hardcording an editor in such way is an ugly hack. :/ No complaining unless it's accompanied by a patch :)
(In reply to comment #12) > No complaining unless it's accompanied by a patch :) Not a complaint, just a note. :-) Well, is my assumption correct that 'sudo crontab -e' will then launch nano instead of vim even for people that have vim installed? It would probably make a lot of them angry. :p Meanwhile, I just symlinked vi -> nano on a system where vim is not installed and the problem was "solved"; but this would probably cause trouble with FEATURES="collision-protect" once you decide to install vim.
Jakub, no, it's only if VISUAL and EDITOR are unset. forcing vi users to use nano would be too cruel and unusual even for me :) from above: /* what editor to use if no EDITOR or VISUAL * environment variable specified. */
IIRC, this was fixed in a new release sometime ago. Please reopen if it's still a concern for anyone else.
