Talk:Invalid shell

/etc/shells

I wrote —

Obviously, you don't want an invalid shell to be listed in the database of standard shells (/etc/shells).

— or do you? There seems to be a difference of opinion about this, and I'm undecided between them. My ISP's SunOS lists ftponly and nologin in /etc/shells. I've always listed these there, when I was running Linux. But the hazard is, it makes it possible for a non-root user to assign itself a non-standard shell, disabling the account - which only a super-user can fix.

On the other hand, some FTP daemons and database authentication schemes require a standard shell, at least by default, even if it is an invalid one and even if the service provides its own shell. What's your view? Should /usr/sbin/nologin be in the shells database? Ninereasons 12:30, 8 June 2006 (EDT)

only if you need it to be

If you're running an ftpd that refuses to allow logins unless the account has a valid shell, then put the shell into /etc/shells get a non-retarded ftpd. Seriously, that chaps my butt pretty badly... I mean, christ, the vast majority of the situations I WANT ftp for involve wanting to give ftp out INSTEAD OF shell access, to allow people to park files on the box without risking them messing about and getting into trouble / trying to run local privilege escalation exploits / etc. If somebody's got a shell, what do they need FTP for? =) --Jimbo 23:19, 8 June 2006 (EDT)