🚀 go-pugleaf

danj1@ihspa.ATt.COM (Dan Jacobson) writes
> login should be a builtin, because if jimmy, used to some other leading
> brands of shell, does
> bash$ login jenny
> as he turns over the terminal to jenny, and then later jenny logs out
> and walks away, jimmy's bash will be sitting there, so some baddie
> will take advantage of it

  [ deleted ]

> Plus it's unreasonable to expect jimmy to memorize "'exec login' when
> under bash".

It's unreasonable for jenny not to expect a trojan horse when jimmy types
	bash$ login jenny
at his terminal and then says "there you go, it's all yours".  Both
jimmy and jenny appear to be in dire need of a basic computer security
course.  Even something as simple as:
	1. "always log out when you leave your terminal"
	2. "never log in unless you're sure a trojan isn't running"**
would do.  If they can't even master these basic points, they have a
whole heap more trouble to worry about than login not being a builtin
in some shells. 

Jonathan H.

** For arbitrary definitions of "sure".

In article <1992Aug7Fr000428a.danj1@ihspa.att.com> danj1@ihspa.ATt.COM (Dan Jacobson) writes:
>login should be a builtin, because if jimmy, used to some other leading
>brands of shell, does
>bash$ login jenny
>as he turns over the terminal to jenny, and then later jenny logs out
>and walks away, jimmy's bash will be sitting there, so some baddie
>will take advantage of it, and then the whole school will hear some
>rumor that bash is a security hazard.  

   I used to feel this way too, but lately I've decided I don't like for
shells to be that clever.  It's even worse for some shells to recognize
"newgrp" and do the same thing they do for login.  It's a misfeature in
those shells. 

>                                        Plus, two out of three selected
>big name shells do it:

   "If a million people do a foolish thing, it is still a foolish thing."  :-)

>Plus it's unreasonable to expect jimmy to memorize "'exec login' when
>under bash".

   If it's really that much of a problem, then I'd suggest putting the
following in /etc/profile:

        if [ -n "${PS1}" -a -n "${BASH_VERSION}" ]; then
           alias login='exec login'
        fi

But think about whether you really want to do this, instead of doing the
Right Thing and getting users to learn about how the shell behaves in the
first place.  If the users are lazy even after that, then they can make
their own aliases.

>>>>> On Sat, 8 Aug 1992 11:53:07 GMT, jch+@cs.cmu.edu (Jonathan
>>>>> Hardwick) said:

JH> danj1@ihspa.ATt.COM (Dan Jacobson) writes
>>>>>>>>>>>>>>>>>>^Like, yo, yo, gnu list maintainers, your e-mail to
news gateway consistently downcases this letter in the "From:" header.

> login should be a builtin, because if jimmy, used to some other leading
> brands of shell, does
> bash$ login jenny
> as he turns over the terminal to jenny, and then later jenny logs out
> and walks away, jimmy's bash will be sitting there, so some baddie
> will take advantage of it

JH>   [ deleted ]

> Plus it's unreasonable to expect jimmy to memorize "'exec login' when
> under bash".

JH> It's unreasonable for jenny not to expect a trojan horse when jimmy types
JH> 	bash$ login jenny
JH> at his terminal and then says "there you go, it's all yours".  Both
JH> jimmy and jenny appear to be in dire need of a basic computer security
JH> course.  Even something as simple as:
JH> 	1. "always log out when you leave your terminal"
JH> 	2. "never log in unless you're sure a trojan isn't running"**
JH> would do.  If they can't even master these basic points, they have a
JH> whole heap more trouble to worry about than login not being a builtin
JH> in some shells. 

But even if jimmy & jenny are best of trusting friends, the problem is
the 3rd party baddie...

JH> Jonathan H.

JH> ** For arbitrary definitions of "sure".

>>>>> On Sat, 8 Aug 1992 23:47:23 GMT, friedman@gnu.ai.mit.edu (Noah Friedman) said:

NF> In article <1992Aug7Fr000428a.danj1@ihspa.att.com> danj1@ihspa.ATt.COM (Dan Jacobson) writes:
>login should be a builtin, because if jimmy, used to some other leading
>brands of shell, does
>bash$ login jenny
>as he turns over the terminal to jenny, and then later jenny logs out
>and walks away, jimmy's bash will be sitting there, so some baddie
>will take advantage of it, and then the whole school will hear some
>rumor that bash is a security hazard.  

NF>    I used to feel this way too, but lately I've decided I don't like for
NF> shells to be that clever.  It's even worse for some shells to recognize
NF> "newgrp" and do the same thing they do for login.  It's a misfeature in
NF> those shells. 

Thanks for reminding me about that massive drag "newgrp" crap in some
shells, I hereby rescind [withdraw] my original complaint.  One less
special twist for "security" is one more step towards a cleaner shell.

>                                        Plus, two out of three selected
>big name shells do it:

NF>    "If a million people do a foolish thing, it is still a foolish thing."  :-)

>Plus it's unreasonable to expect jimmy to memorize "'exec login' when
>under bash".

NF>    If it's really that much of a problem, then I'd suggest putting the
NF> following in /etc/profile:

NF>         if [ -n "${PS1}" -a -n "${BASH_VERSION}" ]; then
NF>            alias login='exec login'
NF>         fi

Probably best put in a specific parinoid person's .profile.

NF> But think about whether you really want to do this, instead of doing the
NF> Right Thing and getting users to learn about how the shell behaves in the
NF> first place.  If the users are lazy even after that, then they can make
NF> their own aliases.

Cool, I agree.  [Like, wowsky... I did a 180 degree viewpoint change.]
-- 
danj1@ihspa.att.com (Dan Jacobson) Naperville IL USA
+17089796364 Chinese~{;}5$Da~}Ji1Dan1ni2