Subject: Re: bin/2905: setting environment vars from login
To: Michael Graff <explorer@flame.org>
From: Christian Kuhtz <kuhtz@ix.netcom.com>
List: netbsd-bugs
Date: 10/30/1996 18:40:13
Alright, I'll try it without the soapbox this time.
On 30 Oct 1996 19:35:19 -0500, Michael Graff <explorer@flame.org> mumbled:
> It is useful from time to time to control how someone logs in.
>
> The LOGIN_ARGS stuff was implimented at ISU, and I often used
> login: explorer -nozephyr (really -nz, but hey)
> login: explorer -nomail
> login: explorer -q (quick, no startup scripts, no locker attaches...)
>
> I found the idea to be very useful.
All of the above can be accomplished without messing with login and purely
by scripting, etc in the shell's rc file, or the system's global master
shell rc.
Also, data is accepted at a point in the authentication stage where one
has absolutely no idea who it is that you are dealing with. But, even
better, this data is passed through to the actual environment of the user
that is authenticated, but at this point isn't.
Have we all forgotten the lousy IFS hacking etc? And all the other attack
patterns? It doesn't matter whether we are setting specific environment
variables explicitly or indirectly.
If we revise our entire authentication scheme which UNIX uses to
authenticate users, we may be able to add such functionality. I don't
think we're about to do that or should dive into that at this point.
> > Guys, login is _-=*AUTHENTICATION*=-_ and not 'add your favorite gimmick
> > here'. And any kind of args have no business in that unless they're
> > directly related and imparative for authentication purposes. Why are we
> > even discussing this??
>
> Because that's what these lists are for... If you don't want to read
> it, kill the thread in your reader.
That's not how this was meant. I agree with you 100% that this is the
place where this type of stuff should be discussed in. Actually, it might
be better to move to another list, like current-users, IMHO, to reach a
broader audience.
The "why are we discussing this" was referring to the rest of my
argumentation which aims at the significance for system integrity and
security. Sorry if I caused a wrong impression here.
> I would love to see the functionality. Perhaps you find it useless, but
> I don't.
This is not about usefulness or uselessness. This is about security and
bloatedness.
One doesn't mess with authentication mechanisms and related pieces of
code, unless it is absolutely neccessary. And the functionality you
advocate can be implemented without modifying an authentication mechanism
such as login. Ergo, it is not absolutely neccessary and authentication
mechanisms do not need to be modified.
That's why I'm against it and think it is a very bad idea to implement.
Not because I love getting on soap boxes or I enjoy making your life
miserable. ;-)
Regards,
Chris
--
Christian Kuhtz <kuhtz@ix.netcom.com>, office: ckuhtz@paranet.com
Network/UNIX Specialist for Paranet, Inc. http://www.paranet.com/
Supercomputing Junkie, et al MIME/NeXTmail accepted
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzJ1JCkAAAEEALzCoYhlxTLI4DID5KpQINF8KM4PUnrZxoL2aRRFAQNX9v9c
8uBySUqVDxfyylB6M/ptUezWIs6DLjz6b8jr8MX40vQf2jU2db6oMDh2axOeXlg2
KCSHryZ9kthnnXOVt0kHLN9XjM9DvwKU28RzvT7umEVmbHFyp64kVG961wkZAAUR
tCVDaHJpc3RpYW4gS3VodHogPGt1aHR6QGl4Lm5ldGNvbS5jb20+iQCVAwUQMnUk
Ka4kVG961wkZAQFztgP+IgHBCz/d1Sc10Qg0Wmu4KnhNb4E4KsPh96V/olwbQS+e
frdWMxSHzX8hGD1p/KbuwlNRrDktmZgVc+n89FGEeGcq3z9WK3o22JsyjJTlzobY
qJIZ5bdOx4dOimQ83ha9zjF+bRnw92t1jC/GJ+LRyOEVMzD5TtL7AMdODO8fNC8=
=sRe0
-----END PGP PUBLIC KEY BLOCK-----