user login goes right to applicaiton, not shell
Distinguished Colleagues,
I basically need a way to restrict a group of users' logins so that
they can't get to the shell when they log in. I only want them to run one
app instead. Previously, this was achieved by putting a while-loop in
.profile that would run one of a couple allowed programs based on user selection. The problem now is that a VPN-type of box was installed where the users connect to the VPN box and it establishes a terminal connection to Sun box, but the VPN box issues its own setup commands to the Sun box that occur during the .profile startup phase, so it messes up the execution of
this while-loop in .profile.
Is there another way to keep the user from getting to the shell when
they log in other than using .profile?
Many thanks,
John
Message was edited by:
BioInformaticsGuy
# 1
... well, technically, if .profile was being read, they had a shell. Anyway, either your applications allow the user to connect directly to it, or you can set restricted shells for those users.
# 3
I have set up ncftp accounts under Solaris 8 where the login shell was set to /bin/false . This allowed access to the server via ncFTP but would kick the user back out if they attempted telnetting into the server. /bin/false had to be added to /etc/shells .
Can you edit /etc/passwd and change the login shell field to whatever application you want the user to access? For example
vipw /etc/passwd
Change
testuser:x:1002:10::/home/testuser:/bin/ksh
To
testuser:x:1002:10::/home/testuser:/opt/apps/bin/myshell
Where /opt/apps/bin/myshell is the path to the application you want to restrict the user to. Initial tests under Solaris 10 were not 100% successful - I hit a problem with the "myshell" program I was using (a very complex menu driven ksh script used to stop, start and monitor our applications) . I think the principle applies so maybe it'll work for you if you have a better application than I do!
One thing I noticed, however. When I backed out the change and put the testuser's shell back to /bin/ksh it took a few minutes for the login process to notice the change in /etc/passwd . It kept trying to start the myshell script for several login and su attempts.
Hope this idea helps,
Colin
# 4
> One thing I noticed, however. When I backed out the
> change and put the testuser's shell back to /bin/ksh
> it took a few minutes for the login process to notice
> the change in /etc/passwd . It kept trying to start
> the myshell script for several login and su
> attempts.
By default, passwd information is cached by the name server caching daemon (nscd). You can kill or restart it to remove the caching effects.
--
Darren
