SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
i think i want the users to view what is in their home directory, and only that. so that a user who try to write cd .. in his home directory only end up in his home directory. the home directory i the users root directory.
Hehe. You could change the file permissions to make the cd command root-only. But that won't change much if they know the system - they can still fsck up the files. But why can't they leave their /home? It is not as if they can change anything anyway, if they are not root?
The "proper" way to do this would involve chroot but then you are going to have to set up an entire mini-filesystem withing their home directory. This might be worth it if you are dealing with allowing members of the general public access to your server (e.g. hosting service) but if this is a general-use workstation or a server for a small group I wouldn't worry about it - *nix in general was built form the ground up to be a fully-multiuser system.
You don't want anything other than their own /home directory to be readable. Do you want any binaries in /bin, /sbin, /usr/ to be executable? The real key is not to give anyone an account that you don't trust.
Last edited by ringwraith; 10-13-2005 at 07:50 AM.
Interesting admin approach, RW: Only allow trusted people on the system.
Of course, this would make you a very hungry ISP...
The right thing here would, perhaps, be to play with group settings where users and members of the group 'users' can't see, well, anything but /home. Then other groups can be defined separately. But there is much work in this.
Originally posted by Gort32 The "proper" way to do this would involve chroot but then you are going to have to set up an entire mini-filesystem withing their home directory. This might be worth it if you are dealing with allowing members of the general public access to your server (e.g. hosting service) but if this is a general-use workstation or a server for a small group I wouldn't worry about it - *nix in general was built form the ground up to be a fully-multiuser system.
chroot is pretty complicated...WIkipedia can explain it better than I
A chroot on Unix operating systems is an operation which changes the root directory. It affects only the current process and its children. "chroot" itself can refer to the chroot(2) system call or the chroot(8) wrapper program.
A program that is re-rooted to another directory cannot name files outside that directory. This provides a convenient way to sandbox an untrusted, test or otherwise dangerous program. It is also a simple kind of jail mechanism.
In practice, chrooting is complicated by programs expecting at startup to find scratch space, configuration files, device nodes and shared libraries at certain preset locations. To allow programs to spawn inside the chroot directory, it must be populated with a minimum set of these files, preferably carefully chosen so as not to allow unintended access to the outside system.
Programs are allowed to carry open file descriptors (for files, pipelines and network connections) into the chroot, which can simplify jail design by making it unnecessary to leave working files inside the chroot directory. This also works as a simple capability system, in which the program is explicitly granted access to resources outside the chroot based on the descriptors it can carry in.