Thayne Harbaugh <[EMAIL PROTECTED]> writes:

> I notice that lsh allows logins when the file /etc/nologin exists.
> lsh still doesn't add information to utmp and wtmp so that who,
> last, and other commands can give information about logins.

This is things that have to be added in due time. The way the code is
organized now, unix_user.c is probably the right place.

> All of these and more (remember password aging and account expiration?)
> exist because lsh doesn't use PAM.  It seems to me that if PAM doesn't
> work well enough to use, then it might be wise to right a login
> library that manages all of these issues.  Then lsh could use that
> library.

Some time ago Marko Kreen gave me a pointer to such a project, some
kind of "non-interactive PAM". Unfortunately I haven't had the time to
look into it, but they might well be doing things the right way.

: I do not know if you have already checked this, but there is available
: 'Pluggable Non Interactive Authentication Modules' project/standard at
: 
: http://www.msu.ru/pniam/pniam.html
: 
: from pniam.html:
: 
: ..
: The main target of PNIAM is a clear and reliable authentication scheme
: for Internet servers. Internet protocols specify a fixed set of requests
: and replies between the server and the client. It makes interactive
: authentication hardly possible. PNIAM deals with a set of requests
: and replies rather than interacts with user.

> I realize that to write the such I library would be time consuming.

It should be possible to get things right without such a library.
After all, the good old rsh program did this right (I hope), without
using PAM or anything like that.

> Right now, however, there are many login subtleties that aren't being
> taken care of.  Ignoring these, however, can leave _serious_ security
> holes.  An admin will think that an account, login, password, or
> whatever is disabled - yet users are still able to login and the logins
> aren't even visible using the expected tools.  I think this is serious
> enough that lsh shouldn't be released until these types of things
> are fixed.

I agree that this is suboptimal. For now, the admin will have to list
processes to see which users are really using the machine, and
shutdown the lshd daemon to disable login that way.

> PS.  Does lsh now understand SIGWINCH??

No, sorry.

Regards,
/Niels

Reply via email to