The host filesystem (hostfs) is a virtual UML filesystem which provides access to the host filesystem. Mounting a hostfs filesystem is done in the same way as any other virtual filesystem -
mount -t hostfs none /home/jdike -o /home/jdike
mounts the host /home/jdike directory on the same location inside UML. The -o switch specifies the host directory to mount. If none is given, the default is the host's /.
There is currently no ability to restrict a UML's hostfs to a given directory on the host. This is needed if hostfs is to be secure against hostile UML users. With this in place, a user inside UML would only be able to mount host directories that are within the directory specified on the command line. Effectively, this would provide a hostfs equivalent of chroot.
Use of hostfs in an environment which is supposed to be secure against hostile UML root users is somewhat problematic. It can be done, but care needs to be taken. To start with, hostfs should be restricted as just described. If restricted to an appropriate hierarchy on the host, UML users will not be able to access files that don't belong to them.
There is still the possibility of using hostfs to launch a Denial Of Service (DOS) attack against the host's disk space. This can be countered by putting disk quotas on the user id of the virtual machine. This will stop any DOS attacks against the host as a whole, but leaves open the possibility of a attack against the quota itself, depriving other virtual machines which share that user id of the ability to use hostfs. This problem can be solved by providing each UML with its own uid. This may be acceptable for a hosting service which is providing virtual machines for paying customers, but is less workable for a public access UML service. In that situation, it likely would be best to not provide hostfs at all.