[plug] telnet server question

[Bernd Felsche]

On Thu, Jul 24, 2003 at 09:18:19AM +0800, Craig Ringer wrote:
> >That's right... I think it'd take the window manager to handle that
> >gracefully... 

> IMHO, the function would ideally be integrated into the login
> manager.  That way, it allows the user to authenticate, then

I was wrong... I agree it should be the login manager because it's
already accessing the display.

> checks to ensure that the shell is in the list of allowed login
> shells. If it is not, the login manager never even starts a single
> process under the authenticated user, but instead informs them
> that their account is disabled.
> 
> Ideally this would be a final pre-login check done in (say) gdm.
> 
> Actually, this is how SCO OpenServer handles it, so it can't be
> that hard!

But that idea isn't worth USD$700. :-)

You can't use /etc/shells... it contains /bin/false, etc. which is
odd because:

<quote>
SHELLS(5)           Linux Programmer's Manual           SHELLS(5)

NAME
       shells - pathnames of valid login shells

DESCRIPTION
       /etc/shells  is  a text file which contains the full path­
       names of valid login shells.  This file  is  consulted  by
       chsh(1) and available to be queried by other programs.

       Be  aware  that there are programs which consult this file
       to find out if a user is a normal user. E.g.: ftp  daemons
       traditionally  disallow  access  to  users with shells not
       included in this file.

</quote>
So clearly /etc/shells should contain only "valid login shells",
which could be interpreted in a couple of ways; the worst being
what's allowed in the shell field of /etc/passwd, or _better_ what
constitutes a "valid login"; making it far more useful for a login
manager of all persuasions.

A warning is displayed when root does a chsh....
	gudgeon:~ # chsh -s /sbin/nologin uucp
	Changing login shell for uucp.
	Warning: "/sbin/nologin" is not listed in /etc/shells
	Shell changed.
But it still works.

How a window manager behaves when encountering an exception (of the
shell not in /etc/shells) is debatable; exec-ing the command and
directing output to a text panel in a dialogue seems like a good
idea. That way the luser has a chance to read and acknowledge the
message from nologin or other "shell" defined by an administrator.

-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | I'm a .signature virus!
 X   against HTML mail     | Copy me into your ~/.signature
/ \  and postings          | to help me spread!