Quote:
Originally Posted by
Mr.AIX
for exsample I want to denied that user to access /usr , /root , /var .... etc
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
