Virtual Address Space Randomization

Randomizing the Virtual Address Space of a process means randomly arranging the address positions of stack, data, executable text, heap libraries etc in an address space. It makes sure that system is secure with respect to various types of attacks based on the knowledge of address locations of key data structures of a virtual address space of a process.

All in all, it is a security measure to make attackers life difficult.

One may need to disable it in some scenarios  For example for using the benchmark tool Filebench, one has to disable it for getting stable results.

sudo su
echo 0 > /proc/sys/kernel/randomize_va_space

NFS: Successful Mount but Permission Denied on Access

Lately, I faced an issue with NFS server. I exported something on the server and mounted the same on a client. Mount was successful but accessing the mount threw “Permission Denied” error. I was unable to list or change directory to the mounted directory.

It happens because of the issues with User ID mappings between client and server. A particular user of the client may not have permissions for the exported directory on the server.

There are multiple ways to get around this. One can use no_root_squash and then use the root user to access the mount. Or one may set permissions of the directory on the server to 777. I would would advise to read about UID mappings in the NFS man page and make decision knowingly.

Following is the description of User ID Mappings given in man page of NFS exports.

User ID Mapping

nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable.
Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called ‘root squashing’) is the default, and can be turned off with no_root_squash.

By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options. Finally, you can map all user requests to the anonymous uid by specifying the all_squash option.

Here’s the complete list of mapping options:


Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.

Turn off root squashing. This option is mainly useful for diskless clients.

Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting.

anonuid and anongid
These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150 (which is supposedly that of user joe).