"Niels M�ller" wrote:
>
> Thayne Harbaugh <[EMAIL PROTECTED]> writes:
>
> > lshd does not appear to log who uses it to log in nor does
> > it seem to show anyone logged in using the w or who command.
>
> There is some code to do this in server_session.c, written by Ray. It
> is currently commented out, because I don't quite understand how these
> things are supposed to work.
>
> lshd ought to log a message when a user is authenticated successfully.
Yes. I'm eagerly awaiting this feature. I'd also like to
see users logins when "who" or "w" is used. Thanks - hope
it's figured out soon.
>
> > Another thing is that it doesn't seem to be configureable
> > to restrict administrative logins, zero length passwords,
> > or various other bad practices.
>
> In general, my plan is to create some separate "user-database"
> abstraction that should take care of things like these. For these
> specific points:
>
> Restricting administrative logins (I assume you mean that root should
> be refused login;
For unix systems I mean any username that is mapped to UID 0 -
not just the username root (things like rewt, admin, foo or
whatever if they map to UID 0 should be controllable).
> to login you have to log in as a user, then su to
> root. And if you have a wheel group, the user would have to be a
> member there) seems like a reasonable feature to add. Perhaps it
> should even be the default.
Yes - I think this should be the default with a way to override
it if someone really wants to login directly as root.
>
> As for zero-length passwords, I'm not so sure. Do you mean
> password-les accounts (empty passwd field in /etc/passwd or
> /etc/shadow), or accounts with the empty string as password?
>
> In the former case, I think lshd should already deny access. Is this
> reasonable? In the latter case, that might well be a problem, but I
> don't think lshd is the right tool to address it.
I really mean both accounts with no password and accounts with
the empty string. Neither or these practices are secure and
should be controllable. Which tools do you think are appropriate
for this?
>
> > What are the plans to address these characteristics/features?
>
> It's not on the top of the TODO list. To fix it, please help to (i)
> specify what behaviour is needed, and (ii) document how to do it. I
> think this list is a reasonable place to figure out the details; i.e.
> what the Right Thing is, what default behaviour is reasonable and
> which things we need options for.
>
> /Niels
