Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a fresh install of CentOS and I'm currently setting up users. Their home directories reside within /home/username/ and I want to make it so that they cannot ls or cd outside that area when they're using openSSH, SFTP etc..

I have been reading through the chroot documentation and I cannot seem to get it working. Any ideas or help would be appreciated.

Many Thanks.

share|improve this question

migrated from stackoverflow.com Mar 2 '12 at 18:12

This question came from our site for professional and enthusiast programmers.

    
Off topic here. But why do you want to forbid users to read files from others (.e.g. from the home directory of people of the same group, willing to share)? And why you users could not list e.g. files inside /usr/bin or other system directories? –  Basile Starynkevitch Mar 2 '12 at 17:32
2  
If you use chroot like this, everything the user needs (executables, libraries, etc.) has to be within the chrooted directory. I've seen ftp servers set up that way, with static executables copied into a bin directory. Ther has to be a working /dev, and probably a lot of other things I haven't thought of. Frankly the whole idea seems like massive overkill. Why do you need the system to be locked down so tightly, and why won't ordinary Linux security suffice? –  Keith Thompson Mar 2 '12 at 23:34
    
@Basile and Keith The reason for disallowing each user to read other user files is that some users have their own 'config.php' files which contain sensitive information, whereas some users dislike the ideas of others being able to see the file structure and source code of their content-management systems, therefore I'm trying to create system where the user has access to their home directory as the top-level folder. I.e. not able to 'cd /' and see everyone else's files, and system folders. I'm guessing from the comments that it isn't that simple. Thanks for your help anyway. –  Arron Jeffery Mar 6 '12 at 19:14
1  
These users should chmod go-rwx their sensitive files. –  Basile Starynkevitch Mar 6 '12 at 19:16
    
Checkout a similar question on Server Fault: "Restrict a Linux user to the files he owns". –  Cristian Ciupitu Jul 18 at 13:59

2 Answers 2

A solution could be to use bash restricted shell. However, be sure to allow only safe commands to be executed from that shell. An example: if less is allowed, a user can exit the restricted shell by using the ! command. To avoid that, set the LESSSECURE environment variable to 1.

share|improve this answer
    
I'm skeptical that you could lock down all "unsafe" commands on a case-by-case basis like that. And what prevents a user from unsetting $LESSSECURE? –  Keith Thompson Mar 2 '12 at 23:29
    
Preventing a user to unset a variable is easy: disable the export builtin with enable -n export. And with control to the PATH, it is possible to lock the execution of only some commands. It is not 100% bulletproof, but it can easily restric 98% of unwanted access. –  jfgagne Mar 3 '12 at 6:14
    
Thanks for the feedback, I think I'm going to give this idea a miss since it seems overly complicated and unsafe. –  Arron Jeffery Mar 6 '12 at 19:17
    
@jfgagne No problem. export LESSSECURE=1 then enable -n export then less /etc/passwd, quite right ! gives "Command not available". However, LESSSECURE="" less /etc/passwd makes ! available and quite capable of dropping me into a shell where even export is available. –  Michael Kjörling Jul 18 at 14:39

The reason for disallowing each user to read other user files is that some users have their own 'config.php' files which contain sensitive information, whereas some users dislike the ideas of others being able to see the file structure and source code of their content-management systems, therefore I'm trying to create system where the user has access to their home directory as the top-level folder. I.e. not able to 'cd /' and see everyone else's files, and system folders. I'm guessing from the comments that it isn't that simple.

Unlike the problem statement in the question itself, that's actually a reasonably solvable problem. Below is one possibility for how to solve that.

First, make each home directory accessible only to its owner, and nobody else. In other words, mode 0700.

Second, set users' umask to 0077. That means that by default, files will be created with group- and world- permission bits set to zero, allowing only owner access.

If the particular file must be accessible by some other process (it's a .php file, so maybe a web server?), give that process its own group membership, set the group ownership on the home directories to that group, and set the mode to 0710. The "execute" bit on a directory allows access if one knows the specific name of a subdirectory or file to which access is desired, but does not allow listing directory contents (that's "read" on the directory).

Any subdirectories under the users' home directories which should be accessible to that same process can have relatively permissive world permission bits. (For example, files 0644 and directories 0755 or 0751.)

If desirable, give users a "share" area, perhaps outside of their home directories, which has a more permissive set of permissions. Maybe for each user, have /home/$USER and /share/$USER, where the directory under /share has 0755 permissions and is owned by the corresponding user. Possibly add a symbolic link in the user's home directory pointing to their "share" directory, and tell them that other users' shared files are in /share/$USER. If you are going this route, you may want to use a umask of 0022 instead, which will default files to be read-only by non-owners. Make sure to inform users that files they store under /share are readable by all users on the system.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.