0

I am using a remote server to do some physics calculations. I found that while a user can't access /home/some_other_user, but he can go to /mnt/disk/some_other_user and look at all the files.

How can I disallow a user to access other users's files from /mnt?

physu
  • 199

1 Answers1

1

Which filesystem type is used for home directories at the remote server? To identify the filesystem type, run e.g. lsblk --fs and look at the FSTYPE column on the appropriate line.

The fact that you can see the files of some other user does not necessarily mean other users can see yours; you should usually be able to set your home directory as inaccessible to others even if other users choose not to do that. (And yes, it would be more secure to have them inaccessible by default and let the users make them accessible if they specifically need to.)

If your home directory contains sub-directories that are supposed to be accessible to others (e.g. webpages in /home/physu/public_html), use chmod 711 $HOME. This prevents other users from seeing the directory listing of your home directory, but if the other user already knows the exact name of the file/sub-directory and that the permission settings of that file/sub-directory will allow that user to access it, they will be able to use it normally. In this configuration, ls -l $HOME should list the permissions of your home directory as drwx--x--x.

For maximum privacy, use chmod 700 $HOME - but before disconnecting, test by establishing another connection to the remote server and logging in. This sets the permissions of your home directory to drwx------ i.e. no permissions at all to anyone but yourself. Sometimes some authentication systems might run as non-root users and require that your home directory is accessible to them. If chmod 700 $HOME stops you from being able to login, use the existing connection to set chmod 711 $HOME instead.

You might also want to contact the administrator of the remote server, particularly if the users' home directories are stored in a filesystem that does not have permissions working correctly and you weren't warned about this fact in advance.

The administrator has probably assigned full permissions to everyone in /mnt/disk, so anyone can create directories there. But you can always control the permissions of anything you create, no matter where they are, because those things are yours. The only way this can be not true in a Unix-like system is if the underlying filesystem does not support file ownerships & permissions (e.g. the FAT32 filesystem).

If you created /mnt/disk/physu for yourself, you can run chmod 700 /mnt/disk/physu and now everything in that directory will be off limits for others.

Run ls -ld /mnt/disk: if it indicates the permissions are drwxrwxrwx, then everyone can create files and directories in there, and everyone can also delete anyone else's files and directories. To prevent that, shared directories like that are often set with permissions drwxrwxrwt, which adds the extra restriction that you must own a thing before you can delete it.

Then run ls -ld /mnt/disk/your_username: what are the permissions now, and is the directory owned by you, or by the administrator? If the administrator has assigned the ownership of that directory to you, then you will be able to change its permissions. If the directory is owned by someone else but you have write permission to it, you can just create a sub-directory in it and make it private:

mkdir /mnt/disk/your_username/private
chmod 700 /mnt/disk/your_username/private

And now, even if you don't get to adjust the permissions of /mnt/disk/your_username, you have created yourself a sub-directory under it whose permissions can be set to exactly what you want them to be.

If you have command line access to a Unix system, there normally should be plenty of places outside your home directory that you must have read access to:

  • /etc/ because pretty much any processes will need to read important configuration settings from there
  • /lib/, /usr/lib/, /bin and /usr/bin so that you can execute commands, and the commands can find the shared library files they need
  • many system components may have important data under /var.

Write access outside your home directory will be much more restricted. Typically you can expect write access outside your home directory only to /tmp/ and /var/tmp/, the standard locations for short-term and longer-term temporary files, respectively, and your local email mailbox file at /var/mail/<username>.

telcoM
  • 96,466
  • I am not well versed with all these technical terms but the administrator has told us to create a soft link to /mnt ( may be because of storage issues ) and do all calculations inside that soft link. So is it possible for the administrator to disallow all others users from accessing /mnt/my_folders. I think I don't have privilege to change permissions for anything outside of /home/my_home. – physu May 04 '20 at 09:16
  • Just another question. Can the root account choose to not allow any user to read, write, excute anything outside of their home directory(/home/user)? – physu May 04 '20 at 09:23
  • See my edit. And in StackExchange, if you have another question, you should generally write another question post. There are ways to restrict a user to their home directory, called restricted shells and chrooting, but those will usually make the restricted account usable for a very specific narrow purpose only. – telcoM May 04 '20 at 10:29
  • It is a directory that grants full access for its owner only, everyone else can read the directory listing (r) and can attempt to access (x) any files or sub-directories in this directory - the permissions of the actual files/sub-directories will determine whether those attempts will be successful or not. Only the owner of the directory can add/rename/delete any files in the directory that has those permissions. See this answer. – telcoM May 04 '20 at 14:04
  • what does the 'd' in drwxr-xr-x indicate ? – physu May 04 '20 at 14:06
  • It indicates that the filesystem object whose permissions you are viewing is a directory. – telcoM May 04 '20 at 14:06