Re: HELP : preventing users from escaping to shell (!sh)

/etc/shells is only used by chsh that I'm aware of -- uucp uses //usr/lib/uucp/uucico as it's login shell quite happily (exact location /varies), and it would never be listed in /etc/shells. The program listed must be an executable, not a script, on every system I've worked on. Your point about shell escapes from within the application is only semi-relevant. The whole point of setting the login program to /bin/xyz_shell is that the SHELL environment variable is set to /bin/xyz_shell, and it should be used to execute the programs when a shell escape is used in the application. This will generally, but not necessarily work. If you want to get really fancy, you could arrange for the password file to specify a chroot() program which traps the user in a ghetto. This is something which the average guru would try with trepidation -- I would not do it -- but it may as well be mentioned for sake of completeness. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> >From: idaniel@jesus.ox.ac.uk (Illtud Daniel) >Date: 30 Jun 1995 12:55:21 GMT >X-Informix-List-Id: <news.15057> > >In article <3sucqi$n1b@news.informix.com>, >Mike Flannery <flannery@informix.com> wrote: >>I don't know if this was already said but in the passwd file you >>can execute any program you want. It doesn't have to be a shell. >>This way when a use logs in instead of even getting to a shell they >>are put right into a program. You could call a script that sets up >>the environment and then executes the program also. This is about >>the same as executing the program from the .profile or .login but >>it is a little more secure. > >But the program that's listed as the shell in the passwd file >has to be listed in /etc/shells - and watch out for shell >escapes from the program itself.