> In fact the proposed changes to login will *not* make it any easier
> to get shell access in a *stock* environment (at least I haven't seen
> any proof to the contrary).

As someone proposing adding a feature, the burden of proof is on you,
to demonstrate that it will not open up new holes, rather than us who
object, to demonstrate that it will.

Given how grossly insecure it turned out to be for telnetd to accept
random environment variables from clients, I, for one, will take quite
a lot of convincing.

>> Just leave the login unable to set environment variables by default.
> If it can be controlled at run-time, then I've no objection.

This sounds as though everyone could be satisifed by adding the
proposed code to login, but requiring a flag to enable it.  If so, the
only prices I see are (a) a slight increment in human time required for
maintenance of the result and (b) the possible increment in insecurity
on systems where the admin turns this flag on.  (b) doesn't bother me
and (a) strikes me as small enough to be ignored, probably less than
the human time wasted by this silly thread so far.

I'd still like to see everything after the username stuffed into a
LOGIN_ARGS variable, but that's another fettle of kish entirely.

> Nobody has yet shown that it will be a risk to the average general
> purpose system (even if it is forced on by default).

It sounds as though about the only thing you'll accept as demonstration
here is widespread implementation followed by a rash of breakins
through that medium and the resulting CERT advisory.

If that's really what it takes...well, don't go away mad, just go away.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D