Why does reading a device require admin permissions?

Question

I'm trying to create a backup script that saves my thumbdrive as an image. I'm planning on having it automatic. I've always seen the thumbdrive listed as /dev/sdb, and created a script that will save it as a gzipped tarball.

While trying to make a copy of it via dd, I noticed this error:

dd: failed to open ‘/dev/sdb’: Permission denied

I wondered if it was just a fluke, so I tried piping a cat command to dd and got this error instead:

cat: /dev/sdb: Permission denied
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000620078 s, 0.0 kB/s

Of course, since I'm a superuser, I can sudo it out -- but that removes an element of the script being automatic.

Why does this device need to have superuser permission if I'm not modifying it? Furthermore, is there a way to bypass this?

Answer 1

Unix/Linux systems are multi-user. Anyone who has read access to a raw storage device can read all the files on it, regardless of who owns the files and their permissions (modulo the filesystem being encrypted, of course). So traditionally the raw devices have only allowed access to root and to members of an administrative group such as operator or disk, and you'd put your trusted admin users or backup operations users into that group.

On GNU/Linux distributions that run udev, 50-udev-default.rules puts all block and SCSI devices in /dev that are not floppies or tapes in the disk group and gives the group read/write permission, so one possible solution for you is to add yourself to that group using usermod or by editing /etc/group directly. Logout and login again.

Answer 2

Why does reading a device require admin permissions?

Firstly there are couple of issues here

1. mount'ing the physical storage device and the partitions it contains.
2. Accessing and manipulating the files on it.

If the filesystem is permissions based, e.g. ext2,3,4 then permissions are defined on a per file basis.

In terms of why you would require the user to have special admin privileges to mount a device there are a few reasons, which are more likely to apply to enterprise type situations and less likely to apply to personal computing - although it still can be relevant

1. It prevents reading in abusive programs Once a disk is mounted an entire collection of untrusted programs are now potentially available for execution which can abuse the operating system. If you were administering that system, you could be more confident that wouldn't happen if casual users couldn't upload their own programs off their own disks.
2. Writing / saving sensitive secret data If you had corporate secrets, or users passwords on a system, and someone could connect an unauthorised storage device they can make copies to it.

You can get around the sudo issue by either running the entire script as sudo, and then using sudo to switch back to an ordinary user inside the script for the commands you dont want to run as root (yes you can do that) e.g.

file: script.sh

#!/bin/sh

# this dd command now works
dd if=<source> of=<target> bs=<byte size>

# normal cammand you want to run as "mathmaniac" user
sudo -u "MathManiac" bash -c "touch foo.bar" 

So you then run this script with:

sudo ./script.sh

Another quick and dirty but generally not recommended way is simply to put sudo in front of the command inside the script, when the interpreter encounters the sudo it will halt script execution and ask you for your sudo password before continuing.

Answer 3

You could use edit the fstab to mount the filesystem without being root but that doesn't give you an image of the block device.

You could edit the sudoers file so the backup script can sudo a specific command without entering a password.