[PATCH] nologin: new applet.

Natanael Copa natanael.copa at gmail.com
Mon Nov 7 14:47:40 UTC 2011


On Mon, Nov 7, 2011 at 4:21 AM, Harald Becker <ralda at gmx.de> wrote:
>  Hallo Natanael!
>
>>> Consider doing a sleep (2 or 3 seconds) after message output before
>>> dieing. If nologin is run via a standard init/getty/login sequence, the
>>> screen is most likely cleared shortly after exit of nologin hence humans
>>> do not have a chance to read the message without a delay. In addition
>>> the delay allows to slow down login attacks (paranoia).
>> I think this tool is intended for passwordless accounts (daemons etc)
>> and this case a delay is meaningless.
>
> True that nologin is for daemon accounts etc. ... but in cases where a
> typo leads to one of those accounts any message vanishes before a human
> can read it.
>
> IMHO is displaying a message without a final delay nothing more than
> calling /bin/false with a different name. I hate such programs don't
> considering the context they are used. And nologin is used in a  context
> where the screen is probably cleared only milliseconds after nologin
> exits (init/getty/login). So that single sleep allow humans to read the
> message emitted by nologin, what else is the reason to emit such a
> message if there is no chance to read?

Well my point is that I have never ever seen this in the getty context
and I have never seen the delay be needed since the user will get a
password error with a proper delay. (i.e if you create a password for
the user account you wouldnt have used noling as shell in first place)

The only times I have ever seen this useful in real life is 1) from
scripts doing 'su something' (very "fun" help some unexperienced
troubleshoot this over phone) 2) someone uploads an ssh key to an
account he shouldnt have used for that purpose. In both those
situations the delay is meaningless but a "This account is disabled"
message is very helpful.

> Is there any situation where that
> delay before exit produces any kind of trouble?

I dont think so but i don't see the point of changing the current
established standard either.

>
> --
> Harald
>



-- 
Natanael Copa


More information about the busybox mailing list