4

If for benchmarking purposes one has to use hdparm or dd directly on the device, I wonder what the correct way would be to do this safely.

Let's say the disk in question is /dev/sda:

root@igloo:~# ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 May 29 08:23 /dev/sda
brw-rw---- 1 root disk 8, 1 May 29 08:23 /dev/sda1

I really don't want to write to sda under any circumstances. So would it be advised to do chmod o+r /dev/sda* and run dd or hdparm on it as a normal user?

10

chmod o+r /dev/sda* is quite dangerous, as it allows any program to read your whole disk (including e.g. password hashes in /etc/shadow, if your root partition is on sda)!

There are (at least) two ways to do this more safely:

  1. Add all users that need to read the disk to the disk group and run chmod g-w /dev/sda* to prevent write access for that group.
  2. Change the group of /dev/sda* to a group that only contains the users that need to read the disk, e.g. chgrp my-benchmarkers /dev/sda* and prevent write access for this group with chmod.

Please note that the group and permission changes on device nodes in /dev are only temporary until the device in question is disconnected or the computer is rebooted.

One problem could be that hdparm needs write access for most of its functionality. You must check if everything you want works with read-only access.

EDIT: It looks like hdparm doesn't need write access. It rather needs the CAP_SYS_RAWIO capability to perform most ioctls. You can use setcap cap_sys_rawio+ep /sbin/hdparm to give this capability to hdparm. Please note that this allows anyone who can execute hdparm and has at least read access to a device file to do practically anything hdparm can do on that device, including --write-sector and all other hdparm commands the man page describes as "VERY DANGEROUS", "EXTREMELY DANGEROUS" or "EXCEPTIONALLY DANGEROUS". Wrapper scripts might be a better solution.

If not you either have to give write access or write wrapper scripts that can be executed by your users as root using sudo rules.

  • 1
    Good answer. I was going to add something similar until it occurred to me that changes made to the ownership and permissions might only persist until the next reboot. I then got side-tracked into researching how to modify udev rules (something I've never had to do, myself). – Anthony Geoghegan May 29 '17 at 12:28
  • 1
    Yes, for persistence udev rules would be the best way. As the question named benchmarking purposes, I assume that there is no need for a completely permanent solution. Luckily there are quite a few answers about udev rules on similar questions: unix.stackexchange.com/a/72446/147970 – cg909 May 29 '17 at 12:46
1

One possibility, although some deployments of /dev might not support it, would be to use an ACL. Example:

$ dd if=/dev/sda bs=1M count=200 of=/dev/null
dd: failed to open '/dev/sda': Permission denied
$ sudo setfacl -m u:youruser:r /dev/sd*
$ dd if=/dev/sda bs=1M count=200 of=/dev/null
200+0 records in
200+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 0.0335544 s, 6.3 GB/s

AFAIK hdparm -t needs to be run as root though.

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.