-1

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.

Improve this question
5
  • 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, 2012 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, 2012 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.
    – Undefined
    Mar 6, 2012 at 19:14
  • 1
    These users should chmod go-rwx their sensitive files.
    – Basile Starynkevitch
    Mar 6, 2012 at 19:16
  • Checkout a similar question on Server Fault: "Restrict a Linux user to the files he owns".
    – Cristian Ciupitu
    Jul 18, 2014 at 13:59

2 Answers 2

Reset to default
0

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.

Improve this answer
4
  • 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, 2012 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.
    – jfg956
    Mar 3, 2012 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.
    – Undefined
    Mar 6, 2012 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.
    – user
    Jul 18, 2014 at 14:39
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .