I was trying to answer this question: Cannot fsck a disk due to no r/w access. To which I replied:

The answer is implied in fsck's output.

Change ownsership with:

# chown username /dev/sdb5
$ fsck /dev/sdb5

Or don't change it and become root instead (probably better):

# fsck /dev/sdb5

If device is mounted, unmount it before.

The alluded fsck output being:

You must have r/w access to the filesystem or be root.

Then another user commented in my answer the following:

Never change the ownership of a blockdevice. It opens security holes and it normally also prevents a normal user from doing something stupid. So the sudo option you describe would be the way to go. Maybe you want to adopt your answer.

And this confuses me, because normally, I would create a filesystem by running mkfs on a block device, e.g. sudo mkfs.ext4 /dev/block_device. So I assumed that to interact with that filesystem I must do it through the block device file. Now, if the file system resides in /dev/block_device, when I change the block device's ownership or permissions, does that mean I'm changing the filesystem's ownership or permissions?

If I made the wrong assumption and these things aren't equivalent, then how does one change the ownership or permissions of a file system?

Or is this something one just shouldn't do? Why?

  • 1
    Personally I'd be extremely uncomfortable with changing ownership of a block device away from root to a normal user. The dangers far outweigh any perceived benefit. Perhaps this is why the changes didn't stick in the forum post that you linked. I for one would consider it a huge security risk. The reason some things can only be done as root is the amount of damage that can occur if they are done incorrectly. I recommend that you change ownership as necessary at the mount point like the rest of us.
    – Elder Geek
    Jul 26 '17 at 0:28
  • FYI sudo for all intents and purposes runs a command with root permissions.
    – Elder Geek
    Jul 26 '17 at 0:36
  • @ElderGreek I think the changes don't stick because the device name assignment is dynamic, I don't know if that counts as a security feature. Anyhow, that's why the poster is told to write an udev rule.
    – Samuel
    Jul 26 '17 at 2:30
  • @ElderGreek Btw, I do things the normal way, using su or sudo. I'm just curious and probably a bit confused by the terminology. The main reason for my confusion being that fsck message, why does it seem to imply that it is ok to change a filesystem/block device's permissions (again, not sure about how these two things relate to each other)?
    – Samuel
    Jul 26 '17 at 4:01
  • See my answer..
    – Elder Geek
    Jul 26 '17 at 17:16

When you change the owner or ownership of the block device, you do not change anything in the filesystem. What happens if you chown the block device to a normal user is, that you completely bypass the filesystem access rights.

A block device is just container that holds unstructured data. The filesystem makes this structured and usable. Normally all users access the block device indirectly through the filesystem, asking to read/open/write files or folders. All based on the access rights that are maintained by the filesystem, granting or denying access to a file or folder.

Now when a normal user has read/write access on a block device, one can bypass those access rights of the filesystem as you can "scratch" files directly form the block device.

Let's walk through.

First we create a folder and file that is only accessible by root, starting with a block device as it should be.

root@host:~# ll /dev/vda1
brw-rw---- 1 root disk 253, 1 Jul 26 18:52 /dev/vda1

root@host:~# mkdir /secure-folder
root@host:~# chmod 700 /secure-folder/
root@host:~# ll -d /secure-folder
drwx------ 2 root root 4096 Jul 27 20:06 /secure-folder/

root@host:~# echo "MySuperSecretText" > /secure-folder/my-secure-file
root@host:~# chmod 400 /secure-folder/my-secure-file
root@host:~# ll /secure-folder/my-secure-file
-r-------- 1 root root 9 Jul 27 19:19 /secure-folder/my-secure-file

This folder and file can only be accessed by the root user and even after changing the owner of the block device, it is still as you would expect.

user@host:~$ ll /secure-folder/
ls: cannot open directory /secure-folder/: Permission denied
user@host:~$ ll /secure-folder/my-secure-file
ls: cannot access /secure-folder/my-secure-file: Permission denied

root@host:~# chown user /dev/vda1 
root@host:~# ll /dev/vda1 
brw-rw---- 1 user disk 253, 1 Jul 27 20:16 /dev/vda1

user@host:~$ ll /secure-folder/
ls: cannot open directory /secure-folder/: Permission denied
user@host:~$ ll /secure-folder/my-secure-file
ls: cannot access /secure-folder/my-secure-file: Permission denied

In this case your filesystem is preventing the user from access files that it does not have access rights to.
But since the user has read/write access to the block device, we can bypass the filesystem. vda1 here is the partition that is mounted on / and debugfs comes with e2fsprogs, so is pretty sure preinstalled.

user@host:~$ debugfs /dev/vda1 -R "ls -l /secure-folder"
  67344   40700 (2)      0      0    4096 27-Jul-2017 19:33 .
      2   40755 (2)      0      0    4096 27-Jul-2017 19:16 ..
  45137  100400 (1)      0      0      18 27-Jul-2017 19:43 my-secure-file

Alright, I can list the directory entries in a folder I do not have access rights. Let's see what else can be done on a file that I do not have access rights on.

user@host:~$ debugfs /dev/vda1 -R "cat /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)

Alright, I can read contents of files this way. Cool. What else could I do? Let's create a folder in a place I normally couldn't.

user@host:~$ debugfs -w /dev/vda1 -R "mkdir /secure-folder/attack"
debugfs 1.42.9 (4-Feb-2014)

root@host:~# ll /secure-folder/
total 16
drwx------  2 root root 4096 Jul 27 19:33 ./
drwxr-xr-x 25 root root 4096 Jul 27 19:16 ../
drwxr-xr-x  2 root root 4096 Jul 27 20:29 attack/
-r--------  1 root root   18 Jul 27 19:43 my-secure-file

Ooops. It even belongs to root although I have created it as user. Hm, what else would be possible? Let's try.

First we need the block number of the /secure-folder/my-secure-file.

user@host:~$ debugfs /dev/vda1 -R "blocks /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)

Okay, block number 913939 contains the data of the file /secure-folder/my-secure-file. Let's use dd to get the content, 4096 is the default block size of ext4 or xfs filesystems. Again possible because I can operate on the block device as a normal user.

user@host:~$ dd if=/dev/vda1 of=/tmp/secure-file skip=913939 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.0214174 s, 191 kB/s

Now we can modify /tmp/secure-file and dd it back on the block device.

user@host:~$ cat /tmp/secure-file

user@host:~$ dd if=/tmp/secure-file of=/dev/vda1 seek=913939 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000356448 s, 11.5 MB/s

Last, as root user let's have a look at the file from the filesystem view. To make it safe we first invalidate all caches to get the content of the disk.

root@host:~# echo 3 > /proc/sys/vm/drop_caches
root@host:~# cat /secure-folder/my-secure-file

root@host:~# ll /secure-folder/my-secure-file
-r-------- 1 root root 18 Jul 27 20:39 /secure-folder/my-secure-file

I have changed a file that belongs to root as normal user and did not have to change any access rights. All based on the fact that I had read/write access to the underlying block device.
This is only a simple example and an advanced attacker could place binary code in your filesystem or exchange well known binaries with malicious ones. Normally the tools used are preinstalled on nearly any distribution.

Well, I must admit that the access rights on the block device are set back when you reboot by udev, but it opens a security issue when you give read/write access to a normal user to a block device.

Hope it's not too confusing and helps to understand the difference between the filesystem and the block device.

  • 1
    Now it's clear to me that changing a block device's file is not equivalent to changing a file system's permissions and the risks it poses even if temporal (which could actually be a long time in a high availability server). Thanks for a detailed and clear explanation.
    – Samuel
    Jul 28 '17 at 18:05

I think you are misunderstanding the implication. as a member of the sudo group you have R/W access by default. This doesn't imply that you are in fact root, just that you have similar access depending upon how sudo is configured.

Further reading:



  • So, then, the correct interpretation of "You must have r/w access to the filesystem or be root" is more or less "You must use sudo or be root"?
    – Samuel
    Jul 26 '17 at 20:14
  • @SamuelSantana IMHO that's more or less correct as sudo by default grants R/W access to block devices.
    – Elder Geek
    Jul 26 '17 at 20:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.