Does anyone with w(write) permission also have the r(read) permission?

There are 3 different levels in Linux file and directory permissions(Read, Write, Execute). In "Linux Basics for Hackers", page 50, write permission is defined as follows:

w Permission to write. This allows users to view and edit a file.

Is it correct to say that viewing a file is equivalent to reading it?

No, write permission does not include read permission, the statement in the book is incorrect. These permissions are independent. If you have write permission only, you can overwrite the file, but you cannot read it. If you have read permission only, you can read the file, but you cannot overwrite it. If you have both permissions, you can do both.

Here is an example. We have a directory with three files, file1, file2, and file3. Each of these files contains a single line of text This is file n (where n=1, 2 or 3) and the permissions are as follows:

raj@jarek-02:~/test$ ls -l
total 12
-rw--w--w- 1 root root 15 Jul 26 19:54 file1
-rw-r--r-- 1 root root 15 Jul 26 19:52 file2
-rw-rw-rw- 1 root root 15 Jul 26 19:53 file3

The files are owned by root, and root has both read and write permission to all three files, but other users (and I'm currently the user raj, as you can see from the system prompt) have only write access to first file, only read access to second one and both read/write access to the third one.

As we can expect, I cannot read the first file, but can read the other two:

raj@jarek-02:~/test$ cat file1
cat: file1: Permission denied
raj@jarek-02:~/test$ cat file2
This is file 2
raj@jarek-02:~/test$ cat file3
This is file 3

Let's try to overwrite the files now.

raj@jarek-02:~/test$ echo "Overwriting file 1" > file1
raj@jarek-02:~/test$ echo "Overwriting file 2" > file2
bash: file2: Permission denied
raj@jarek-02:~/test$ echo "Overwriting file 3" > file3

First and third command succeeded (because there was no output), and the second one failed with a "Permission denied" message.

Now try to display the files again:

raj@jarek-02:~/test$ cat file1
cat: file1: Permission denied
raj@jarek-02:~/test$ cat file2
This is file 2
raj@jarek-02:~/test$ cat file3
Overwriting file 3

I still cannot display file1, although I was able to change it. file2 did not change (as there was a "Permission denied" message when trying to change it), and we can see that file3 did change.

To verify file1 has changed as well, let's try to display it as root user, who has read access to the file:

root@jarek-02:/home/raj/test# cat file1
Overwriting file 1

So in fact the user raj, having write access, was able to change the file's contents, but neither before nor after changing it cannot read the file.

No, as the other answers have pointed out, the statement in the book is wrong.

Write-only files/directories are actually used in a couple of ways in real life:

• In /proc and /sys, write-only files used when the file serves the purpose of signaling something to the kernel in an event-oriented manner but there is no useful associated state for the user to query. The most common cases are files under /sys used to explicitly bind or unbind drivers, and the cgroup.kill and memory.reclaim files found in v2 cgroups (which are used respectively to atomically kill all processes in the cgroup, and to manually trigger memory reclaim in that cgroup).
• Write-only directories are often used for file-upload systems. Users can write to the directory, but not see what’s in it. This is significant because it ensures that users cannot see what other people have uploaded.
• Shared hot-directory setups sometimes also use write-only directories, for essentially the same security reason that they’re used for file upload directories.
• In some cases, a log file for a given service may be write-only for the user that service is configured to run as. This works because logs are append-only (so the service just seeks to the end when it opens the file, and then starts writing), and it ensures that logs cannot be read an attacker who compromises the service in some way.

More generically, the idea that any permissions on Linux or other UNIX-like are implicit is generally wrong. In the classic UNIX DAC model, there are exactly zero implied permissions, everything is explicitly codified. The same is true of POSIX ACLs, NFSv4 ACLs, and all the MAC systems I know of for Linux. The possible exception is some Linux Capabilities, but those only look implicit if you don’t understand what is actually being checked.

This is important because implicit permissions are dangerous. Because they’re not explicitly codified, it’s easy to forget about them, and forgetting about them will often lead to security issues.