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-----