The Node

Posts Tagged ‘mount’

On your Internet travels, you may have come across CD image files with a .bin or .cue extension. You might even hypothetically want to mount these files under Linux and read their contents. It’s very easy once you know how and here is how you do it.

The utility that makes this possible is called bchunk. Your friendly Linux software repository will no doubt have it. For Red Hat-based systems this means running: -

yum install bchunk

and for Debian-based systems, this means running: -

sudo apt-get install bchunk

BIN and CUE files are extensively used as CD file image formats in burning software under Windows but is less supported on other platforms where the now more common ISO file format is used. The difference between the two is largely irrelevant to this topic but suffice to say the entirety consists of the BIN file which holds the actual data and a text CUE file which acts as an index of the data. To convert the files to ISO, simply run: -

bchunk yourfile.bin yourfile.cue yourfile.iso

…where the first parameter is the BIN file, the second is it’s corresponding CUE file and the last is the output ISO file.

For mounting this resulting ISO file on to your Linux file-system, create a mount point directory for it and run: -

mount -o loop -t iso9660 yourfile.iso /mnt/yourmountpoint

That’s it! Simple but useful.

I’ve already covered setting up FTP via vsFTPd in a previous article, but FTP is old and not terribly secure even these days. SSH is far better for accessing Linux machines in almost every scenario. From SSH tunneling to shell access to file transfer, it’s desirable to use for it’s security and flexibility. However, I found SSH problematic when trying to confine users to their home directories and didn’t want them viewing the rest of the system. SFTP (part of SSH) allows you to do this and with more recent versions of OpenSSH, it’s much easier to configure than it used to be.
So you want to allow SFTP access to your server but don’t want them to be able to wander around the system. Even with user privilege security that means they won’t be able to ruin the system, they’ll still be able to see the file-system. This is where you need what’s known as a chroot jail, which means that they cannot “get out” of their own home directory. I covered how to do this with regular FTP in the article above, but let’s modernise the situation and do it with SFTP instead.

At this point it’s worth pointing out that in order for this to work, you’ll need OpenSSH version 4.9p1 or higher. While chroot jails could be accomplished before this version, it involves the use of third-party tools that basically didn’t work terribly well. Assuming you’ve got that version or higher, let’s get started.

Also, don’t use regular users who require normal shell user access for this. Create user accounts specifically for using SFTP as the user won’t be able to add any file or directories from the shell even if they change users from another user using the su command. They certainly won’t be able to login normally via SSH as they won’t have shell access for this purpose.

I’ll be using Fedora Linux for this, but it’s virtually identical to other distributions aside from the location of the sshd_config file.

First, edit the sshd_config file with:-

vi /etc/ssh/sshd_config

Add the following, skipping any lines that might already be present but making sure that the “Match” line is near the bottom of the file. Comment out any existing Subsystem line and replace with the “internal-sftp” directive instead.


Subsystem sftp internal-sftp -f LOCAL5 -l VERBOSE
Match Group sftp
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no


Save this and return to the command line. Restart the sshd daemon for the changes to take effect with:-

service sshd restart

This basically tells OpenSSH that all users in the “sftp” group (which we will create in a moment) are to be chrooted to their home directory (which the %h represents in the ChrootDirectory command) and forces the use of the internal-sftp helper and disables TCP port forwarding. The Subsystem command is required to enable the use of the SFTP subsystem. This can either be a path to the sftp-server helper which is present in Fedora, or the internal-sftp, which we’ll use instead. The internal-sftp command apparently works better and doesn’t require a shell or extra libraries installed in the chroot location. I’ll not be covering chrooted command shells just yet because it’s damned difficult to make it usefully functional and I’ve not looked into it yet :-)

Next we’ll need to create the “sftp” group which we’ll add the users on our system that we want to confine to a jail. Do that with: -

groupadd sftp

Now, for any users you want to add to chroot, perform the following steps for each, which adds the user [USER] to our newly created “sftp” group for SFTP.


usermod -G sftp [USER]
usermod -s /sbin/nologin [USER]
chown root.root /home/[USER]


The usermod command adds [USER] to the “sftp” group and set’s their shell to “/sbin/nologin” which means that they absolutely cannot ever get shell access – we’re only dealing with chrooting SFTP here, not SSH shell access. The chown command will set the home directory owner to root. While this seems odd as home directories are normally owned by their users, this is needed for the chroot jail to work.

If you want read access only, run the command:-

chmod -R o-w /home/[USER]

or the following for read/write access – which is normally the default if you’ve just created a new user for the purposes of SFTP and simply changed the owner of the /home/[USER] directory to root.

chmod -R o+w /home/[USER]

While you can do it this way, this has some obvious security flaws (everybody else = write access). A better alternative is to create two directories for uploads and downloads and set appropriate permissions with the following as root:-


cd /home/[USER]
mkdir uploads
chown [USER].[USER] uploads
chmod ug+rwx uploads
mkdir downloads
chown [USER].[USER] downloads
chmod ug+r downloads
chmod ug-w downloads


The user can then upload/download files to/from the “uploads” directory and only download files from the downloads directory. SFTP chroot jails simply cannot write files or directories to the root of the chroot jail even as that user. This is simply a functional limitation of chrooting the user to their home directory which is achieved by having the /home/[USER] directory owned by root.

One last thing to note is that I sometimes use symlinks and user permissions to give access to other parts of the system outside the chroot jail. This absolutely won’t work in this situation. Instead, you can simply double-mount the directory the symlinks points to.

For example, say I had the symlink with appropriate permissions under the user’s home directory called “linky” which points to “/some/path”. Instead delete the symlink with the following, remembering to do all this as root of course, as the mount command requires it.


rm /home/[USER]/linky
mkdir linky
chmod ug+rwx linky
mount --bind /some/path /home/[USER]/linky


Use the -t switch also if the file-system is not your native Linux file-system type. Done!

Usually you mount hard drives and USB devices automatically on boot using their device partition names in your /etc/fstab file, something like: -


/dev/sdb1 /home ext4 defaults 1 2


However, this won’t necessarily give you the mount points you expect, especially if your “/etc/fstab” file contains “/dev” devices that are USB external hard drives. This sometimes happened to me when I rebooted my server and found that the device usually mounted under “/home” was mounted in a different place defined in “/etc/fstab” simply because the boot process found the devices in a different order. So the contents of “/home” actually ended up mounted somewhere else, like “/usr/local/backup”. Not good.
This is because the devices under “/dev” are not unique to the hard drive or other device on boot – it’s simply ordered in the order in which your Linux system found them upon loading. However, every device attached to your system actually has a unique identifier to that piece of hardware called a UUID or Universal Unique ID. So you need to find a list of these UUIDs and the devices they relate to.

Under Red Hat-based systems, you can use the “blkid” command to get the UUID for devices. “blkid” is a command-line utility to locate/print block device attributes, including the UUID. If you run the command, you’ll see something like: -


/dev/sda1: UUID="d5428817-bfa9-466c-850d-42545dc06248" TYPE="ext2"
/dev/sdb1: UUID="01d0599a-2733-4779-bc01-50e7748e29eb" TYPE="ext4"
...


This will also usually work under Ubuntu or Debian-based systems. If not, finding out the UUIDs for your devices is a little more involved, but not much. You can use the “vol_id” command to find out the UUID for a specific device, but you have to go through all of them manually with a command like: -


sudo vol_id --uuid /dev/sdb2


Make a note of these UUIDs and then edit your “/etc/fstab” file with: -

vi /etc/fstab

under Red Hat systems as root and:-

sudo vi /etc/fstab

under Ubuntu systems (the only difference being already being the root user on Red Hat and using sudo to elevate your security in order to edit the file). You can now replace the “/dev/[device]” with the UUID like so:-


UUID=43813f50-0a19-40d1-9aba-7b345a78e695 /home ext4 defaults 1 2


This will then always load the specific device at the specific mount point, regardless in which the order of devices is found by the system.