restricting users to a directory 4

[matth]

How do I restrict my developers to a specific directory so they can not touch my production area? So far I have created a new user, I have there login to drop them into a directory, (/test) but they are still able to wander through the rest of the system. I think I know how to keep people out of a directory by using "chmod", but how do I keep them in a directory?

 

[PSD]

Matth,

You could look at the restricted bourne shell i.e. :

/usr/bin/Rsh

Look at the man page.

If you add the following line to the users .profile:

/usr/bin/Rsh

Then when the user logs in the cd operation is not permitted hence they are in effect stuck in their home directory. Look at the man page for full details of the shell.

Best of Luck

Paul Sharpe-Deacon
HACMP Specialist

 

[cspilman]

Yes, Rsh will work in this case.

From my experience though, it is better to put the /usr/bin/Rsh statement in the /etc/passwd file instead of the users .profile in their home directory. The reason for this is that if it is a statement in their .profile, during login, if done right (can be tested yourself) you can break out of the .profile execution, hence, not actually execute the Restricted shell.

If it is placed in the /etc/passwd file, they are forced to used /usr/bin/Rsh before they are actually logged in and there is no way for them to break out that.

Good Luck,
Chuck

 

[PSD]

Matth,

I would concur with Chuck that the /etc/profile is a more secure method of invoking the Rsh.

Bear in mind that you will be able to vi the /etc/passwd file and change the default shell for existing users, but in the longer term for new user creation you are best editing the /etc/security/login.cfg file and adding the /usr/bin/Rsh string to the list of allowed shells. This means that for future users you can actually type in the inital program field in smit : /usr/bin/Rsh . Without editing this file you would have to take the default korn shell option and then vi the /etc/passwd file for every new user . Just something else to do if you implement this on your system.

Best of luck

Paul Sharpe-Deacon

 

[matth]

Thanks for the replys. They are helpful. One quick mention, when the system was delivered, the man pages were not installed (someone gave me A LOT more credit then I deserve). I will play around with it some more using the advice and attempt to get this fixed.

Thanks again,

Matthew

 

[d3funct]

Another way I've found to handle a similar situation. The last place I worked they wanted me to create a user named "download" which they would log into just to download batchjobs and they wanted me to make it so "download" couldn't cd from the directory, but the system didn't have Rsh loaded on it. So, since they needed this done soon I created the user "download" and aliased the command cd to equate to /dev/null, I also did this with any other commands a user using "download" might try to use to give explicit commands (i.e., /usr/bin/cd), I modified the path for "download" so that they couldn't issue absolute pathnames and then gave root ownership of the .profile and chown'd it 700. It worked at least until we got Rsh put on the box, I never found out why it wasn't installed originally. d3funct
borg@pcgeek.net
The software required `Windows 95 or better', so I installed Linux.

 

[matth]

It took a while to get the Rsh going (it wasn't in the login.cfg file). It looks like it does what I want it to do, but as an apparent side effect, the user can not "ls". Any ideas?

Thanks for everything,

Matthew

 

[matth]

I noticed that I am doing this through smit. When I try to switch the shell after I have gone through my start up, it does put me into the environment that I want. I have been setting the initial PROGRAM to /usr/bin/Rsh and after login, I am not able to "ls". Anyone know what I am missing here?

Thanks again,

Matthew

 

[ElgisRamon]

Are you sure is the [tt]ls[/tt] command blocked? The restricted shell doesn't permit ANY command with / (slashes) in it (or any redirection symbol!)

 

[matth]

Here is the message I get when I type "ls":

ls: 0653-345 .: Permission denied

As I was saying earlier, if I switch after the login is complete, I am able to "ls", however, I am getting the above message if I set that as the initial PROGRAM in smit.

Matthew

 

[PSD]

Matth,

I guess I would check two things:

1) When I log in the output of echo $SHELL

is it definitely /usr/bin/Rsh and /usr/bin/rsh?

2) What is the directory you are placed in on login? is it the users home directory?

ls should work in the Rsh, unless the directory they are being put into does not have the correct permissions. check the permissions.

HTH

Paul Sharpe-Deacon

 

[d3funct]

why not just copy the commands you want/need into the users home bin directory? d3funct
borg@pcgeek.net
The software required `Windows 95 or better', so I installed Linux.