In reply to bug 349729 Martin Schulze <[EMAIL PROTECTED]> wrote: >Please read the advisory again: >http://www.debian.org/security/2006/dsa-946 > >It says: > > "Additional variables are only passed through when set as env_check > in /etc/sudoers, which might be required for some scripts to > continue to work." > >[the advisory indicates only LC_*, LANG, LANGUAGE and TERM are passed through]
[ The discussion is now merged into: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349587 ] Out of interest what was the rationale for omitting $HOME from this list? Omitting it (when -H and/or set_home and/or always_set_home isn't in effect to overwrite $HOME) results in an environment without $HOME set at all. Since $HOME is one of the variables set by login(1), and rarely stripped out, a lot of (interactive) programs assume that it'll be set. Most recently I've encountered issues with vim complaining that it can't read/write $HOME/.viminfo (due to passing the literal string '$HOME/.viminfo' to open(2), since there was no variable to do expansion on). Obviously as a work around we can all do: Defaults env_reset, env_check = HOME on every single system we use that runs Debian. But if there's a security issue involved in passing through $HOME then I think it should at least be documented so that we can be aware of it when deciding to either put this work around in place, or live with the warnings when doing "sudo vim foo", etc. If there's no security issue then $HOME seems like an obvious candidate to add into the default whitelist. (The only other variable set by default by login(1) which isn't now set in the "sudo sh" environment is $MAIL, and that doesn't seem particularly important in the context of sudo.) Ewen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
