I got email yesterday from a user who had run 'from' and got the message
"No mail in /home/stevev/$USER" (where $USER was that person's
username). At first I thought he had pilfered my .bashrc, but on
further investigation I discovered that my home directory path had been
compiled in to sshd, because the configuration tests assume that the
directory part of $MAIL is the systemwide mail spool. Unfortunately on
this system we deliver mail into user home directories, so we set MAIL
to $HOME/.mail rather than /var/{,spool/}mail/$USER, and this user's
shell initialization did not change MAIL from the default set by sshd.
Given that I'm doing something nonstandard, an answer of "don't
configure OpenSSH with your funky setting of MAIL" is reasonable
enough. I can't really think of any clean solution to put into the
Portable OpenSSH code base to address this; I may end up tweaking our
local source tree so we get the right thing for our users, but this is
an interesting configuration problem that people might want to know
about.
On Fri, Apr 06, 2001 at 12:18:18PM -0700, Steve VanDevender wrote:> I got email yesterday from a user who had run 'from' and got the message > "No mail in /home/stevev/$USER" (where $USER was that person's > username). At first I thought he had pilfered my .bashrc, but on > further investigation I discovered that my home directory path had been > compiled in to sshd, because the configuration tests assume that the > directory part of $MAIL is the systemwide mail spool. Unfortunately on > this system we deliver mail into user home directories, so we set MAIL > to $HOME/.mail rather than /var/{,spool/}mail/$USER, and this user's > shell initialization did not change MAIL from the default set by sshd. > > Given that I'm doing something nonstandard, an answer of "don't > configure OpenSSH with your funky setting of MAIL" is reasonable > enough. I can't really think of any clean solution to put into the > Portable OpenSSH code base to address this; I may end up tweaking our > local source tree so we get the right thing for our users, but this is > an interesting configuration problem that people might want to know > about.Are you sure the real problem isn't that sshd is started with your environment at runtime? I recently had a similar problem with inetd. Try starting it like this: env -i PATH=/some:/reasonable:/subset /usr/local/sbin/sshd -- David Terrell | "The fact that you can't name the place dbt at meat.net | you're going to die doesn't mean you http://wwn.nebcorp.com/ | shouldn't pay attention to your health." -whg3
Is there anyway for it to evaluate, at runtime, say $HOME? As your mailspools are under each users's home directory, if I read correctly... Unfortunately I have no machines which I can test this on easily at the moment. (At least not with greatly upsetting a few people...) Just a thought. --Matt> -----Original Message----- > From: Steve VanDevender [mailto:stevev at darkwing.uoregon.edu] > Sent: Friday, April 06, 2001 1:15 PM > To: David Terrell > Cc: openssh-unix-dev at mindrot.org > Subject: Re: $MAIL surprise > > > David Terrell writes: > > Are you sure the real problem isn't that sshd is started with your > > environment at runtime? I recently had a similar problem > with inetd. > > Try starting it like this: > > > > env -i PATH=/some:/reasonable:/subset /usr/local/sbin/sshd > > That was my first thought too, and I restarted sshd with "env -i" on > that host and it didn't change anything. I looked and here's > what's in > config.h: > > /* Set this to your mail directory if you don't have maillock.h */ > #define MAIL_DIRECTORY "/home/staff/stevev" > > So then in defines.h this happens: > > #ifndef MAIL_DIRECTORY > # define MAIL_DIRECTORY "/var/spool/mail" > #endif > > #ifndef MAILDIR > # define MAILDIR MAIL_DIRECTORY > #endif > > #if !defined(_PATH_MAILDIR) && defined(MAILDIR) > # define _PATH_MAILDIR MAILDIR > #endif /* !defined(_PATH_MAILDIR) && defined(MAILDIR) */ > > And finally in session.c this environment variable setting is created: > > snprintf(buf, sizeof buf, "%.200s/%.50s", > _PATH_MAILDIR, pw->pw_name); > child_set_env(&env, &envsize, "MAIL", buf); > > And this is what is in configure that gets it all started: > > # Check for mail directory (last resort if we cannot get it > from headers) > if test ! -z "$MAIL" ; then > maildir=`dirname $MAIL` > cat >> confdefs.h <<EOF > #define MAIL_DIRECTORY "$maildir" > EOF > > The code in defines.h should use _PATH_MAILDIR if it's defined in the > system headers, but at least in the case of the Solaris and SunOS > systems where I'm seeing this happen, there is no setting for > _PATH_MAILDIR in the system include files. > > Like I said before, though, I'm not really arguing that this code or > this approach to finding $MAIL is wrong, but it is surprising. >
At 12:18 PM -0700 4/6/01, Steve VanDevender wrote:>... At first I thought he had pilfered my .bashrc, but on >further investigation I discovered that my home directory path had been >compiled in to sshd, because the configuration tests assume that the >directory part of $MAIL is the systemwide mail spool. Unfortunately on >this system we deliver mail into user home directories, so we set MAIL >to $HOME/.mail rather than /var/{,spool/}mail/$USER, and this user's >shell initialization did not change MAIL from the default set by sshd. > >Given that I'm doing something nonstandard, an answer of "don't >configure OpenSSH with your funky setting of MAIL" is reasonable >enough. I can't really think of any clean solution to put into the >Portable OpenSSH code base to address this; ...What happens for your mail programs if you set MAIL to ~/.mail (with the ~ literally in the environment variable, don't let the shell expand it out when the value is being set). Do your applications understand ~ = $HOME ? If so, then openssh could at least recognize ~ (which it may already do...), and you might have one plausible option. Or at least, you could COMPILE openssh with that value set, even if you can't just arbitrary set that for all users. Another option MIGHT be to see what happens if the value for 'MAIL' is literally '$HOME/.mail' (again, without having $HOME expanded by the shell when setting the variable), but I suspect this is less likely to work in other email applications. More importantly, that then means that openssh's behavior depends on an environment variable the user can directly change, and that does not sound like a good idea to me. -- Garance Alistair Drosehn = gad at eclipse.acs.rpi.edu Senior Systems Programmer or gad at freebsd.org Rensselaer Polytechnic Institute or drosih at rpi.edu