Why do you need superuser permissions to read the real-time clock on Linux?

Question

The real-time clock /dev/rtc can be read using hwclock -r but only as root.

>hwclock -r --debug
hwclock from util-linux 2.23.2
hwclock: cannot open /dev/rtc: Permission denied
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.
>sudo hwclock -r
[sudo] password for xxx: 
Wed 26 Apr 2017 12:44:01 BST  -0.281946 seconds

I can't think of any good reason to prevent any user from reading a clock. So why is root acess required here?

My only thought is that it must be something to do with a low-level query that could somehow interface with the system. Perhaps if you continually read /dev/rtc you could block it long enough to upset the kernel?

Context: I am now responsible for an application which reads from /dev/rtc. Because of this it must run as root but there is no real reason it couldn't be a userspace application. I question its need to use the real-time clock at all but my question still stands.

Lapoint

Answer 1

It's an artifact of the way access to RTC is implemented in Linux: the /dev/rtc* devices can be opened only once (until they are closed) and they are read-only. Reading and setting the RTC is then done via calls to ioctl.

Additionally, it makes sense that only the superuser can set the RTC, an action which may have destructive impact on the system. Therefore only the superuser should be able to open the RTC devices.

As it is, that leads to the rtc* devices belonging to root user & group, even though there are conceivably other ways to implement this restriction. One could, for instance, allow every user to open the devices, and checking for proper privileges on the ioctl call. Read access to the device can even be given on a per-user basis, via uaccess, etc.

---

Per the RTC kernel documentation, there's two more interfaces to the RTC:

• The /proc/driver/rtc is a pseudo file providing some status information. On my system(s) it offers read access to all, but I can't find any spec on that.

• The /sys/class/rtc/rtc* entries are backing the corresponding /dev/rtc* devices (which you can find out if you cat /sys/class/rtc/rtcN/dev), and also offer (via "attribute" files) read access to all on date, time, seconds since Epoch, etc. Triggering uevents, modifying the max interrupt rate, and time to request a wakeup event are only offered to root (MODE 0644).

Promiscuity

Are you saying that in order to set the real-time clock /dev/rtc is opened read-only? That is very counter-intuitive. – Lapoint

Your answer is correct but there is a little more to the story: see kernel.org/doc/Documentation/rtc.txt There are two other interfaces to the rtc both of which are available from user space /proc/driver/rtc & /sys/class/rtc/rt0. So its more a case that the old API has not been altered or removed. man rtc is not very helpful in this regard. hwclock might be more useful if it knew about the userspace APIs. – Lapoint

I'm guessing the correct ettiquette is to ask you to add that to your answer and to accept it rather than adding an answer of my own? – Lapoint

Answer 2

You're obviously hitting file permissions here:

hwclock: cannot open /dev/rtc: Permission denied

In my system (openSUSE 42.1) only root can read/write to /dev/rtc0. Modern Linux distributions use udevd (now it is part of systemd) to create device nodes in devtmpfs. If you look into systemd source, you can see that there is no directives for setting permissions for rtc devices: systemd/rules/50-udev-default.rules:9

# select "system RTC" or just use the first one
SUBSYSTEM=="rtc", ATTR{hctosys}=="1", SYMLINK+="rtc"
SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc", OPTIONS+="link_priority=-100"

I may only speculate that not so much apps require RTC access, so that was a reason why they didn't create special group for that (like for tty)

Trocar

That's also a reason: applications are supposed to use the system clocks instead of the RTC devices. – Promiscuity