I noticed that the mknod command required root privileges when a creating a node other than a regular file, FIFO or a Unix socket.

Why is that? How can a regular user harm a system or compromise other users' privacy with the mknod command that he can't when creating regular files?

  • Don't worry you can use fakeroot mknod...!
    – Pandya
    Commented Jan 18, 2016 at 15:54
  • 1
    @Pandya fakeroot mknod /dev/fake-dev0 b 7 200Permissions denied. Nope, it doesn't work.
    – Hi-Angel
    Commented Mar 27, 2018 at 6:59
  • 2
    @Hi-Angel fakeroot mknod ~/test b 8 0 does actually work. The reason it doesn't work under /dev is because you don't have permission to create files under /dev as a regular user... Commented Jul 19, 2019 at 7:35
  • 1
    @WouterVerhelst I tried that and indeed a file is created without errors... but that's a regular file, so not that useful if you ask me. Commented Dec 26, 2022 at 19:03

4 Answers 4


If you could call mknod arbitrarily, then you could create device files owned and accessible by you for any device. The device files give you unlimited access to the corresponding devices; therefore, any user could access devices arbitrarily.

For instance, suppose /dev/sda1 holds a file system to which you have no access. (Say, it is mounted to /secret). Over here, /dev/sda1 is block special 8,1, so if you could call mknod, e.g. mknod ~/my_sda1 b 8 1, then you could access anything on /dev/sda1 through your own device file for /dev/sda1 regardless of any filesystem restrictions on /dev/sda1. (You get the device as a flat file without any structure, so you would need to know what to do with it, but there are libraries for accessing block device files.)

Likewise, if you could create your own copy of /dev/mem or /dev/kmem, then you could examine anything in main memory; if you could create your own copy of /dev/tty* or /dev/pts/*, then you could record any keyboard input - and so on.

Therefore, mknod in the hand of ordinary users is harmful and thus its use must be restricted.

N.B. This is why the nodev mount option is crucial for mobile devices, for otherwise you could bring in your own device files on prepared mobile media.


With mknod, you create device-special files that allow raw access to the hardware. That is, the kernel looks at the device-special file's permissions to decide whether a given user is allowed raw acess to hardware, not to anything in configuration or some such.

E.g., on Debian, devices related to optical drives are created with 0660 permission bits, user root, and group cdrom; so anyone who is either root or in the cdrom group can do things like "create an image using dd of /dev/dvd rather than through a mounted filesystem." That might not mean much to you until you realise that the same thing happens for your hard disks (e.g., /dev/sda) to which you would also be able to write.

While device-special files are conventionally created under the /dev directory, there is nothing inherent in the Linux system that requires it; any filesystem (that isn't mounted with the nodev option) can contain device nodes. The only thing that links a device node to the actual device are the type (block or character) and the major and minor nodes.

Thus, if regular users would be able to create device-special files, then they would be able to bypass all kernel security and access all hardware directly by simply creating a device-special file (in their home directory, say), and using that to nuke the hard disk.

As such, creating device-special files can only be done by root.


After the regular, FIFO and socket file types, mknod can also create device files. These are used to access devices.

Granting access to devices is considered a privileged operation. Generally, we don't want to create arbitrary device nodes and make them accessible to regular users. That would be Bad.

[Aside: Typically device access is granted by changing the permissions on an existing device node instead. On standard Linux, /dev/ is controlled by udev, so you muck around with extra udev rules].


$ mount|grep -w /
/dev/mapper/vg_fossil-root on / type ext4 (rw,seclabel,data=ordered)

$  ls -l /dev/mapper/vg_fossil-root
lrwxrwxrwx. 1 root root 7 Jan 18 08:46 /dev/mapper/vg_fossil-root -> ../dm-0
$ ls -l /dev/dm-0
brw-rw----. 1 root disk 253, 0 Jan 18 08:46 /dev/dm-0

As root:

# mknod root-partition b 253 0
# chmod a+rw root-partition  # make file available as if created as a normal user

Now I have direct access to the device which stores your filesystem.

$ ls -l root-partition 
brw-rw-rw-. 1 root root 253, 0 Jan 18 15:05 root-partition

I can read data from files I wouldn't otherwise have permissions on

$ grep secret root-parition
Binary file root-partition matches

Or remove the "echo" in front of this next command, and your filesystem will no longer exist.

$ echo dd if=/dev/zero of=root-partition


After creating extra device files to play with, you can remove them safely without damaging anything.

$ rm root-partition

Unless of course you make a mistake and remove the wrong file, or perhaps literally all the files. This command will not provide undo/undelete or prompt for confirmation. The command line is unforgiving :). The sole protection is that without -r or *, it will not remove any directories.


You could use mknod to access device files in a chroot "prison" (e.g. the device for the root file system)

You must log in to answer this question.

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