13

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?

2

3 Answers 3

23

viewing is indeed reading but write permissions does not include read permissions so that sentence looks wrong to me.

/proc and /sys have pseudo files that only have write permissons. It is used for one-way signaling; so to trigger an event (ie. if there is a value in the file do an action otherwise do nothing; and the process that handles this clears the value). Don't think there is really a usage for it in normal life.

sudo find /proc/[^0-9]* /sys -perm /222 ! -perm /444

finds them (it sums up to about 5600 files). As an example:

$ ls -ltr /sys/module/snd_rawmidi/uevent
--w------- 1 root root 4096 jul 26 15:34 /sys/module/snd_rawmidi/uevent

Write, no read. And even the owner (root) can not look at it:

rinzwind@schijfwereld:~$ sudo -i
root@schijfwereld:~# more /sys/module/snd_rawmidi/uevent
more: cannot open /sys/module/snd_rawmidi/uevent: Permission denied
4
  • 15
    Typical usage in normal life is an upload directory -- people can write new files to the directory, but not read what has been uploaded so far. We used that quite often on multiuser machines to send each other files -- just copy them to ~otheruser/upload. Jul 27, 2023 at 10:28
  • 6
    @SimonRichter the term for that is a "drop box", mirroring the term for the physical boxes it was common to find in banks and post offices. Anyone can put stuff in, but only the owner can get stuff out. Of course then the company Dropbox had to come along and muddy the terminology.
    – OrangeDog
    Jul 27, 2023 at 11:48
  • 1
    You can't make assumptions based on /sys files. Each one individually connects to a piece of code in the kernel that can do whatever it wants to, including returning a permissions error for something the permissions actually allow. Jul 27, 2023 at 17:34
  • 2
    1) When I have a named pipe, I may want it to be write-only for the producer so that if it does try to read it'll error out instead of hanging forever. 2) Or a log file that various programs write to, but should not have read access for security reasons. And on and on...
    – webmarc
    Jul 28, 2023 at 11:38
16

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.

1
  • You can extend your answer by including explanations about directory permissions too.
    – FedKad
    Jul 27, 2023 at 19:49
6

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .