Freeze user in one directory

Guy's

I have user calld appuser

home directory of this user is : /app/application

when this user login , user will be direct under this directory /app/application

I want to keep and freeze this user in his home directory to be able to access only his home directory and denied it to access any other directories

for exsample I want to denied that user to access /usr , /root , /var .... etc

only has access to his home directory

Please assist and advice in this regard !

Hi,
you want to implement a chroot jail.
Just make sure the user has all resources (shared libs,...) he needs available within his jail.

Stefan

This is not quite possible: if you deny a user access to the "/usr" tree he will not be able to execute any commands stored there - which, in case of the "/usr" hierarchy - includes all the commands a Unix system has. The user would, for instance, not even be allowed to change his password, because the "passwd" command lives in "/usr/bin/passwd".

Of course there is "chroot", as has been mentioned, but this means basically replicating the (relevant part of the whole) system into a single directory, creating a copy of the /usr tree, etc.. You still will need to give the user access to at least these copies, otherwise you have the same situation as before. Further, the user has to log into the system to do some (meaningful) work: it might be possible that the restrictions you put onto the account at the same time prevent the account from doing anything meaningful at all.

You might explore the "restricted shell" ("ksh -r") to achieve your desired functionality, but even this is IMHO a desperate measure.

As long as you get your authentication model and your privilege model right you don't need to fall back to these solutions of last resort, though - not in most of the cases, that is. It doesn't hurt if a user can see something, as long as he isn't able to change it - which is, why there are "r" bits and "w" bits to set on a directory and file level.

So, as long as you don't explain which situation calls for such outrageous security mechanisms the best advice i can give you is: don't do it. Use normal file/directory restrictions instead, not even considering ACLs.

I hope this helps.

bakunin