Debian bug report logs - #1667
chsh can change the login shell to anything

Message received at debian-bugs:

From i17linuxb.ists.pwr.wroc.pl!marekm Fri Oct 13 07:35:04 1995
Return-Path: <marekm@i17linuxb.ists.pwr.wroc.pl>
Received: from pixar.com by mongo.pixar.com with smtp
	(Smail3.1.28.1 #15) id m0t3lCS-000DMWC; Fri, 13 Oct 95 07:35 PDT
Received: from i17linuxb.ists.pwr.wroc.pl by pixar.com with SMTP id AA05061
  (5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Fri, 13 Oct 1995 07:34:37 -0700
Received: (from marekm@localhost) by i17linuxb.ists.pwr.wroc.pl (8.6.12/8.6.9) id PAA01745 for debian-bugs@pixar.com; Fri, 13 Oct 1995 15:34:43 +0100
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Message-Id: <199510131434.PAA01745@i17linuxb.ists.pwr.wroc.pl>
Subject: chsh can change the login shell to anything
To: debian-bugs@pixar.com
Date: Fri, 13 Oct 1995 15:34:41 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1139      

Package: chfn
Version: 1.0-4

This is even documented in the man page, but I think this is wrong:
for ordinary users, chsh should only change the shell to one of the
valid shells listed in /etc/shells (and only if the shell actually
exists and is executable), and only for users who have a valid and
not restricted shell.

The -l (--list-shells) option should only list the shells which are
listed in /etc/shells AND executable by the user, otherwise it is
the same as "cat /etc/shells".

Believe me, on a system with 100 users or so, users who forget their
passwords cause enough trouble.  I don't want users to be able to
screw up themselves so easily and then go to me to fix their login
shell :-(.

Typical example: user logs in over a modem (noisy phone line - this
is quite common here in Poland, the maximum usable speed is often
300bps :-( ) and the new login shell has just one character wrong.
They will notice the warning message, but after a while the modem
drops the connection due to too much noise and the user can't log
in again to fix the problem.

There are good reasons for the traditional UN*X chsh behaviour...

Marek