Subject: Checking /etc/shells for access

From: David Lee <[email-masked]>
Date: Tue, 23 May 2000 17:01:17 +0100 (BST)

Being a university, we have many thousand registered users with procedures
for adding and removing them.  The removal process is at least two-stage: 
before the final chop, we block the account for a few weeks. 

When so blocked, their id/pw combination is still valid, but we replace
their shell with our own program that prints a message for them see.  It
then exits, so they can't (in theory, at least) do anything useful.

All this makes re-instatement (in case of error, or last-minute
re-registration) considerably easier than if we expunged all trace of them
immediately.  (Philosophy: where reasonably possible, deliver explanatory
text to the user, such as at login (with forced logoff), but try to
prevent them doing anything useful.)

It seems that in this blocked state, when our intention is that they
should not be able to do anything useful, they can still use IMAP and POP. 

Is there some functionality in IMAP/POP/c-client which, in the same manner
as a typical FTP daemon, will check the user's shell against "/etc/shells"
and prevent access if there is no match?

Does such an idea seem useful?  I'm happy to try to implement it.

It would be nice if there were a global config file for IMAP/POP in which
the a "check for /etc/shells" option could be set.  (But the nearest
thing, "/etc/c-client.cf", seems to be highly non-recommended, according
to the dire warning text in "docs/imaprc.txt"!) 

Thoughts, anyone?

--

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Tue, 23 May 2000 13:18:59 -0700 (PDT)

> and prevent access if there is no match?

The problem with having such a functionality is that it is not for everybody.
Some people use their systems' existing /etc/shells functionality to create
"IMAP only" users.

In my opinion, the best way to disable a user completely is to insert a "*"
character in front of the password, e.g.:
	fred:*ern5WpvPF/zIj:105:69:Fred Foobar:/u/fred:/bin/ksh
This will prevent fred from logging in with any service, and all you have to
do to re-enable him is to delete the *.

---

From: David Lee <[email-masked]>
Date: Thu, 25 May 2000 15:20:55 +0100 (BST)

> do to re-enable him is to delete the *.

That's one way.  But we do something different, for reasons given below,
hence my question. 

We leave the id and pw valid, and change the "shell" field in the "passwd" 
database to a program that prints a message and exits.  That way, the
telnet type of user user gets a useful message, to tell her/him about the
imminent deletion and advising them who to contact if they believe this is
in error.  For us and our users this is preferable to ubiquitous message
"Login incorrect".

I think what we choose to do is reasonable (although I'd be glad to hear
of alternatives from other 10,000-user sites).  So it seems reasonable
that checking "/etc/shells" (as does the ftpd daemon) might at least be a
site-configurable option.  (OK, it cannot deliver the text that they would
get at telnet-login, but their failure to collect mail would at least
alert them that something, somewhere needs attention.)

Thoughts?

--